General

This readme describes ArchEx demo problems for Reconfigurable Production Lines (RPL). An RPL consists of a source that provides units (parts, details) to be processed (assembled, packaged) on the production line, a set of machines connected by conveyors and a sink that collects the final product. A typical shop floor can have several RPLs of different product types. Reconfiguration is, in particular, related to having different operation modes, i.e., dynamically adjusting product flow rates according to current needs. A controller can launch/stall different machines and forward production units to other (in)active lines if required.

It is currently possible to solve existing RPL problem formulation with monolithic optimization, because it terminates in several minutes. Future extensions are planned to introduce more sophisticated path and timing constraints, which may require the use of the iterative approach as well.

Solutions to demo problems (MAT files and graphs) can be found in the Demos/RPL folder.

Outline

• environment configuration
• how to select and run demos, see the results
• descriptions of demos problems and expected results
• notes

Environment configuration

Please refer to these pages for more information on installing and using ArchEx.

Instructions

The demo version can be launched with a script RPL_Demo.m. Open the script and have a look.

Select a problem

After the header there is a "Demo problem input file" section. Here one can select a particular input file name for a problem. When launched, ArchEx will be called with this name as problem input, i.e., all but one of them must be commented out.

To switch between the demos just uncomment the required one and comment the previous. You don't have to modify anything else in the script.

If you want to view/modify the txt files of the problems or the library, you can find them in Problems/demos and Libraries/demos, respectively.

Run

To start the demo, from the Matlab command line type:

RPL_Demo

There is currently no GUI, so all the output prints will be shown in the console. After the execution is finished, final results of reliability analysis, elapsed time and total number of iterations will be shown there.

Execution is finished when "Done saving" is written in the console.

View results

When the solution is found, ArchEx will draw a graph that illustrates it. All graphs are post-processed to show different component subtypes in different colors. For this demo components that process product types A,B,C have, respectively, green, yellow and cyan colors. Reconfigurable machines, i.e., those, which can process several product types (e.g., AC, AB, ABC) have red color.

In the graph window there are several useful functions: change the size of the nodes and change the font size. They can be used to make the picture more readable.

By double clicking on the node one can open a description window, where information about the library component, to which the node is mapped, is shown (HINT: if you try to click again and again and nothing happens, try to decrease the font size of node labels).

Graphs are saved as PNG to Output/graphs.

Matlab data (e.g. adjacency matrix, flow rates, elapsed time etc.) is saved to a .MAT file in the Output folder.

It is possible to redraw the graph (e.g. if it was closed accidentally) by typing in the console:

prob.ShowResult

The value of the cost function (which is the monetary cost of the architecture in the EPN problem) can be seen by typing:

prob.CostFunction

Descriptions of demo problems and expected results

There are four demo problems for RPL. You can find them in Problems/demos folder. They are named RPL_DEMO(1-4).txt. Below there is a summary of the scenarios. More detailed information can be found in corresponding TXT files.

RPL_DEMO1

This is the default demo selected in the RPL_Demo.m script. The RPL has two product types (A,B) and, respectively, one source and one sink (collection point) for each product, and two machines along the functional flow (each unit is processed first in Machine1 and then in Machine2). Architectural template consists of maximum 3 machines/conveyors for every processing stage (functional flow) for product A and 2 machines/conveyors for product B.

There are two operation modes: O1 = 1A+1B, O2 = 2A+0B. In O2 production of B is stalled, i.e., machines and conveyors on line(s) B can be reused for processing units of A (if existing machines on A (sub)lines cannot handle the input flow). For more details please refer to [1].

The cost function is the sum of monetary costs of machines and conveyors (graph nodes) as well as junction conveyors (horizontal edges that connect conveyors together, i.e., moving production units/details from one conveyor to another). For exact cost values one can refer to DEMO_RPL_LIB.txt (library).

Flow constraints are enforced on each component to ensure that input product flow is equal to output product flow. Additionally, there are Load constraints for machines to make sure that they can process all input traffic (input flow rate is less than or equal to machine's processing rate). Connectivity constraints are used to enforce legal infrastructure of an RPL. For example, if a machine has an input conveyor attached to it, then it must have an output conveyor as well (to move parts down along the production flow).

Currently, monolithic ("eager") optimization is used to solve RPL problems with acceptable timing (several minutes). Resulting architecture demonstrates, that the optimizer can decide to reuse the idle machines of other product lines (e.g. forward units of A to line B) to support required operation modes by using reconfigurable machines.

Expected result

• Total number of machines: 4
• Reconfigurable machines (red color): 2
• Total idle rate of machines: 28 units/sec
• Cost: 65000
• Elapsed time: ~1 min

RPL_DEMO2

Second demo is intended to demonstrate, how the architecture changes if we limit the total idle rate of machines using a timing constraint.

The optimal architecture from RPL_DEMO1 has machines with larger processing rate, which is cheaper than having several sub-lines with slower machines. However, in this case the resource of these fast machines will be utilized at around 25-30% in several operation modes, which means that they spend more time in "idle" state instead of "active" (working). The cost of a machine and/or of a business process often includes the utilization rate, i.e., it is important not only to minimize the monetary cost but also to maximize the fraction of total time, in which the machine is performing its task (is not idle).

In this demo, the architecture is more expensive in terms of monetary cost of machines and conveyors as it has more sub-lines with slower machines, however, these machines are utilized at around 90% of time.

The execution time of this demo might be slower due to additional constraint.

Expected result

• Total number of machines: 8
• Reconfigurable machines (red color): 2
• Total idle rate of machines: 8 units/sec
• Cost: 74000
• Elapsed time: ~2 min

RPL_DEMO3

ToDo

RPL_DEMO4

This demo is an example of an unfeasible problem. Similarly to RPL_DEMO2, the max_total_idle_rate pattern is used to limit the idle rate of the system. However, in this demo the requirement is too tight (5 units/sec) and hence no feasible solution is found.

Expected result: UNFEASIBLE

• Cost: 0
• Elapsed time: ~1-2 min

Notes

1. Results of all four demos can be found in the Demos folder (no plots for RPL_DEMO4, because the problem is unfeasible).

2. A library txt file RPL_DEMO_LIB.txt can be found in Libraries/demos.

3. For the demo version printing of CPLEX messages to the console is switched off (solver is called with minimum verbose).

4. If there is no solution then the graph of the latest iteration is not drawn, not saved as PNG as well. The Matlab and CPLEX data is saved in any case. "UNFEASIBLE" is written to the console.

5. Resulting graphs can be different from those stored in the Demos folder because sometimes there can be several symmetrical solutions (equivalent in terms of cost function and other results). In this case the system cost can be compared to the one from this readme and if they are same then solutions can be considered identical.

References

1. D. Kirov, P. Nuzzo, R. Passerone and A. Sangiovanni-Vincentelli. "ArchEx: An Extensible Framework for the Exploration of Cyber-Physical System Architectures". In Proc. of the 54th Design Automation Conference (DAC), 2017.
2. N. Bajaj, P. Nuzzo, M. Masin and A. Sangiovanni-Vincentelli. "Optimized Selection of Reliable and Cost-Effective Cyber-Physical System Architectures". In Proc. Design, Automation and Test in Europe (DATE), 2015.