General

This readme describes the ArchEx demo version for EPN (Electrical Power Network) of a passenger aircraft. It is intended to show to a user how to solve several different EPN problems and compare the results. It is suggested to solve demo problems with the iterative ("lazy") approach (ILP-MR), because it takes several minutes, while solving with the monolithic ("eager") appoach (ILP-AR) for the demo EPN problems may take hours. One can find the solutions of demo problems with ILP-AR in the Demos folder for comparison.

Outline

• environment configuration
• how to select and run demos, and see the results
• descriptions of demo 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 EPN_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:

EPN_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 "End solving" is written in the console.

View results

The iterative ("lazy") approach will draw a resulting graph for each iteration of the algorithm so one can see visually the differences between them and the final result (which is the last iteration graph). All graphs are post-processed to show different component subtypes in different colors. For this demo High voltage components are green, Low voltage are yellow and TRUs are red. Unused nodes are not shown.

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 (only final) are saved as PNG to Output/graphs.

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

It is possible to redraw the final 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

To re-run the reliability analysis (and see its result) type:

prob.Analysis.Run

Descriptions of demo problems and expected results

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

EPN_DEMO1

This is the default demo selected in the EPN_demo.m script.

This demo synthesizes an architecture for a template, which is similar to the one in the Honeywell patent. It has 16 loads (8 each part). There is a High voltage (HV) part and Low voltage (LV) part. Constraints include restrictions not to connect HV and LV components together (it is possible only by using a TRU - Transformer-Rectifier Unit).

Half of the loads, both HV and LV, are sheddable (reliability requirement is 1e-5), second half is critical/non-sheddable (requirement is 1e-9).

There are two engines (one left and one right), each of which has a HV generator and a LV generator. There is also a possibility of using either 1 or 2 APUs.

Resulting architecture can demonstrate the speed of the "lazy" algorithm and the possibility of synthesizing an architecture similar to the one from the real EPN patent. One can observe, that an LV DC bus is connected to a HV AC bus with a TRU, which demonstrates the necessity of a connection between HV and LV parts to satisfy the requirement. At the same time we do not force the optimizer to provide a "symmetric" architecture (i.e. TRUs on both left and right sides) and so it decides that the second TRU is not needed to decrease the overall cost.

Expected result

• Reliability: 0.38e-9 (HV), 0.19e-9 (LV)
• Cost: 108000
• Elapsed time: ~1-2 min
• Iterations: 3

EPN_DEMO2

Second demo is intended to demonstrate, how the architecture changes if we account also for bus requirements (i.e. each bus must be able to power all loads connected to it). This requirement is currently implemented only for DC buses and loads directly connected to them (not via other buses).

Run the demo. If you compare to EPN_DEMO1, there are two more DC buses, one HV and one LV, and, consequently, two more AC buses. It can also be seen that now two TRUs are used to connect LV DC buses to HV AC buses. This happens, in fact, because there are no solutions with more than 2 LV AC buses - there are no generators to connect them to (two LV generators are already occupied and it is not possible to connect LV bus to an APU).

Resulting architecture is, of course, more expensive due to extra buses and, as a result, the need of using the second APU.

The timing of running this demo is a bit slower, because the final reliability analysis takes more time (due to more buses and many horizontal connections).

Expected result

• Reliability: 0.32e-13 (HV), 0.51e-13 (LV)
• Cost: 143000
• Elapsed time: ~4-6 min
• Iterations: 2

EPN_DEMO3

Third demo tightens the interconnection constraints by declaring that TRUs MUST be used only for connecting LV and HV parts. In this case the optimizer won't try to use them as simple rectifiers to connect, for instance, HV buses (for the sake of lowering the cost).

Resulting architecture is redundant (more buses used), more expensive than EPN_DEMO1 (having the same reliability requirement) but cheaper than EPN_DEMO2.

Execution time of this demo is also slower than EPN_DEMO1 (due to long reliability analysis of the final architecture).

Expected result

• Reliability: 0.64e-10 (HV), 0.1e-12 (LV)
• Cost: 131000
• Elapsed time: ~2-4 min
• Iterations: 3

EPN_DEMO4

This demo is an example of an unfeasible problem. It is equivalent to EPN_DEMO1, but with two extra constraints, which say that an APU must be connected ONLY to AC buses, which are also connected to a normal generator (only HV).

First two iterations of the "lazy" algorithm are OK, but on the third iteration the learning function decides to add more HV AC buses. But there are only two HV generators (non-APUs) and already two HV AC buses are in use. With the abovementioned APU constraints it is not possible to connect new buses to an APU only and there are not extra HV generators available. As a result, the solver returns UNFEASIBLE.

Execution time is similar to EPN_DEMO1, because the solver still makes 3 iterations before concluding the unfeasibility.

Expected result: UNFEASIBLE

• Reliability: 0
• Cost: 0
• Elapsed time: ~1-2 min
• Iterations: 3

Notes

1. Results of all four demos (both for "lazy" and "eager" algorithms) can be found in the Demos folder (no plots for EPN_DEMO4, because the problem is unfeasible).

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

3. LearnCons() function prints its moves to the console when it's called. One can get useful info on what decisions does the heuristic make.

4. For the demo version printing of CPLEX messages to the console is switched off.

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

6. 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.