Tech Days 2015: Model Based Development with QGen

Editor's Notes

• #32: Let’s take a look at QGen’s ability to generate Ada code. We’ll try three different code generation strategies: the first is the most straightforward and generates one file for every atomic subsystem; the second inlines all code, allowing for more optimization by both QGen and the conventional cross-compiler; and the third strategy corresponds to Simulink’s “generate reusable code” mode, which requires wrapping the persistent state in a record type to reuse the same algorithm with different input data.
• #33: The model we present here is a hierarchical model composed by both atomic and virtual subsystems. [00:17] We’ll now generate code using the most straightforward code generation strategy. To show the model, we use GPS, AdaCore’s IDE for Ada and C development. [00:34] As you can see, QGen generated one file for every atomic subsystem. If we look within the generated code, we see that it is not only very readable but contains precise traceability information in the form of comments. [01:02] Now let’s generate code in inlining mode. After reloading the project inside GPS, we see that QGen has generated just two files. If we look inside these files, we see that the code has been inlined preserving precise traceability information and locality of statements with respect to the subsystem hierarchy. [01:45] Finally, we’ll generate reusable code. So let’s reload the project inside GPS. We see that QGen has produced an additional file that contains the record types for the persistent state and Input/Output of the model. If we look at the generated code, we notice that it has the same structure, is equally traceable, but now uses these new types to access the model persistent state and its I/O.
• #47: In this demo, we’re going to use QGen to look for bugs, and in particular division by zero. As you can see, the red-circled block is a division block whose input is not protected against potential divisions by zero. The model we see here represent the speedometer of a car.
• #48: [00:10] The subsystem contains the speedometer algorithm, which relies on Simulink libraries. [00:15] So let’s look for bugs in the model. In order to do this, we’re going to firstly produce a verification model, then analyse it and then ‘round-trip’ the analysis results back to the model. We discover that there is a potential divsion by zero in this block (00:38). [00:43] To solve this issue, we’re going to add some defensive modeling in the Simulink model by checking whether the output of the yellow block is equal to zero. If this is the case, then we produce a constant value equal to 1 as output, so as to avoid the division by zero. [01:08] We then save the model, and re-run the verification. This time, no potential errors have been found.
• #53: This time, we’ll be using QGen to formally prove properties that have been formalised as Simulink Assertion blocks. The Simulink model describes the behaviour of a cruise control system in a car and the safety property we want to prove, is the following: “If the driver hits the brake or clutch pedal, then the cruise control is deactivated”
• #54: [00:10] This model represents the cruise control logic. The safety property has been formalised as a Simulink Assertion block whose input represents the truth table we just saw on the slide. [00:20] The subsystem, however contains the logic of the cruise control, that is the algorithm that regulates its activation and deactivation depending on the driver’s input. [00:32] So now, let’s formally verify the model. First of all we need to produce a verification model, then we’ll analyze it and finally roundtrip the verification results back to the model. [00:40] The result of this verification turns out to be an error in the Assertion block. In the next line, we have some more detailed information on why the Assertion block might fail, and in particular, we see that the block causing the error is the Switch block (00:52). Frankly there are no surprises here as the input of the switch block is an ‘AND’ operator between the Brake and the Clutch state. This means that our implementation requires the brake and clutch to be hit at the same time to deactivate the cruise control. (01:00) This contradicts with our safety property which required only one of them to be hit. [01:04] What we can do now is change the operator from AND to OR, save the model and re-execute the verification. In this case, no potential errors are found.
• #65: 1. We show the generated_src directory containing nothing 2. We edit the project file to show that we say that we use the Simulink language, and where the generated code needs to be placed 3. Click on the .mdl file to open the graphical display of the Simulink model 4. We can click on subsystems to navigate through the model 5. There is a contextual menu to generate the code from the Simulink model 6. Once the code has been generated we can show that the generated_src directory contains the generated code 7. We can open the pid.adb file to show how the generated code looks like, and the traceability comments that QGen places there 8. We can build the application 9. We can open the debugging session 10. We can put the model and the source code side by side (and they will be kept synchronized automatically) 11. We can display the variable computed by the model (V) 12. We can use the contextual menu to set a breakpoint in a block (we see that corresponding breakpoints appear in the sources) 13. We can display variables from the generated code (Unit_Delay_Out1) 14. We can “continue" several times and see we reach the block where we set the breakpoint 15. Clicking on “next” we go to the next block that is executed 15. Clicking on “step” we enter the into the nested subsystems 16. Clicking on “finish” we leave the scope of the current subsystem and go into the one that contains the current 17. And at the end we can show the tooltips with the values of the different variables at execution time