New in 2.9.0! Using the new (experimental) DSE perspective
AutoFOCUS 3 supports an approach for supporting the system designer by generating platform architectures, deployments (mapping of components to platforms) and schedules (timing information of a deployment).
These DSE features have already been part of AF3 for two years in the modeling perspective
(see Platform Generation, Deployment Generation, State Automatons).
The new perspective for these activities should make these features easier to access with a improved usability. (Note that this feature is experimental up to this point and is
not supporting all of the DSE activities, offered in the modelling perspective, yet).
If you want to open the DSE perspective you have to click on the open perspective button and select the DSE perspective.
DSE Project Explorer
Now the DSE perspective opens and the main menu is visible. On the upper left hand side you can see the DSE Project Explorer. Here you can select the project which you
want to work on. It is important that it has a DSE Object attached. If you didn't add one in the modeling perspective you can simply right click on the project and
select "create new DSE".
Double clicking on the project makes it active and so you can do a design space exploration with this project.
DSE Navigator
In the DSE Navigator you can see all generated platforms, deployments and schedules in a tree like view. The DSE Navigator also has a history functionality
meaning that it displays all formerly generated objects. By double clicking on a generated deployment or schedule a visualization of the same will open up on the right.
All objects generated through the Platform Generation View, Deployment Generation View and Schedule Generation View will be displayed here. The lastly generated objects are highlighted yellow.
Constraint Navigator
The Constraint Navigator is similar to the DSE Navigator. It displays all constraints which where modeled in the Constraints Editor in a tree like view.
Quick Help
As soon as you open DSE Perspective, you would get to see a Quick Help view. It offers several functionalities as follows.
- Quick Menu
- Used to open Quick Menu
- Switch to Modeling
- Used to switch to Modeling Perspective
- Show AF3 Help
- Opens AutoFocus 3 Help
- Show Error log
- Opens AutoFocus 3 Error Log Browser
Quick Menu
You can use all the top-level functionalities of DSE Perspective using this Quick Menu. As soon as you open DSE Perspective, you can see the following screen.
This quick menu placed in the middle of the aforementioned image does provide the following functionalities.
- Select Project
- Indicates status of Component Architecture presence in the selected project
- Indicates status of Platform Architecture presence in the selected project
- Indicates status of Deployment presence in the selected project
- Opens Constraint Modeling View
- Opens Platform Generation View
- Opens Deployment Generation View
- Opens Schedule Generation View
- Opens Schedule Visualization View
- Opens All Deployment Visualization Views
MULTI-RATE SCHEDULE GENERATION (experimental)
Since Release 2.9 AutoFOCUS3 supports the generation of multi-rate schedules.
If you open the Schedule generation view as stated above, there exists a section which enables the generation of
multi-rate schedules for a certain deployment. In order to do that, you have to fill in periods for each
deployed component (task) in the attached table. Additionally, you can manipulate the computation times (or WCET) of the tasks and
the sending times of the signals. PIC and GCD describe two different methods of calculating a multi-rate
schedule. The difference between the methods is the handling of task interrupts. Where GCD uses a static
approach, the GCD approach uses a dynamic approach to calculate interrupts. This affects especially
schedules with varying period. In this case a schedule generation using the GCD option might not find
any solution whereas the PIC approach will most probably provide a solution.
Deployment Generation Constraints
An important DSE problem is deployment and schedule generation. To help the user generate safe and reliable deployments, we have added some constraints
which need to be satisfied while generating the deployments and corresponding schedules. The constraints can be added in the "Constraint Modeling View".
Until now there exists only one constraint which can be used for any DSE step. It is the allocation or dis-location of components onto specific hardware units.
(All further constraints are only for DSE steps using a PikeOS Architecture and are explained below.) An allocation constraint means that a specific component has
to be deployed onto a certain execution unit. A dis-location constraint means that a specific component must not be deployed onto a specific execution unit.
In order to add one of the two constraints you have to drag and drop a component on the left to the upper table (allocation) or to the lower table (dis-location)
and hit the add button at the bottom. This constraint will then be visible in the "Constraint Navigator" on the left.
The Constraints for generation using the PikeOS Platfrom are divided in different groups as listed below.
-
PMHF Node Constraint
(SafetyDimension)
-
PMHF Bus Constraint
(SafetyDimension)
-
Memory Constraint
(NodeUsageConstraint)
-
Node Usage Constraint (NodeUsageConstraint)
-
Cost Constraint
(CostConstraint)
-
Energy Consumption Constraint
(EnergyDimension)
Before defining each of these constraints, we need to have a look on the properties that are added for logical components and technical components. The values of these properties
are defined using the Annotation view. In case of "ACC" system model, the annotation view for the logical architecture is shown in the figure below.
The annotation view of the technical architecture is shown as follows.
After defining the values of the properties in the annotation view, the constraints can be selectively added using the DSE Perspective. This is shown in the figure below.
 |  |
Once the constraints are added, they can be used as a part of deployment generation process. By adding them to deployment generation process, we form a constraint satisfaction
problem which is solved using a Z3 solver. These constraints are defined as follows.
-
PMHF Node Constraint - Given the SIL levels for each logical component and hardware node (ECUs), the PMHF Node Constraint ensures that
each logical component is deployed only onto a safety compatible hardware component.
-
PMHF Bus Constraint - This constraint ensures that the communication between two logical components must be carried without ignoring the reliability (i.e. SIL level) of
the communication medium. In other words, the SIL level of the receiving component needs to be at least as strict as the SIL level of the communication medium.
-
Memory Constraint - Since each logical components requires some amount of memory to execute, the Memory Constraint makes sure that none of the
Hardware Nodes (ECUs) run out of memory while accommodating the logical components.
-
Node Usage Constraint - This constraint simply limits the maximum number of nodes that can be used in the given technical architecture. The upper limit of node usage is defined
by the user.
-
Cost Constraint - Another important constraint is the cost constraint. Each hardware node (ECU) is given a cost label, which might depend on factors such the developmental effort
and time required to implement its functionality. The total cost of the hardware architecture is calculated by adding the individual costs of the nodes that are used. So, the cost
constraint ensures that the total cost of the hardware architecture does not exceed the value entered by the user.
-
Energy Consumption Constraint - Each hardware node (ECU) is given a power label. The energy consumed by each node is calculated by multiplying the power label of the node by its
non idle time. The non idle time of a node is calculated by adding the individual runtimes of the logical components allocated to the node. The energy consumed by each node is then
added to yield the total energy consumption of the hardware architecture. So, the Energy Consumption Constraint ensures that the total energy consumed does not exceed the value entered
by the user.