Osate 2 Arinc653 Framework
The ARINC653 framework for AADL is an OSATE2 plug-in that aims at providing support for designing AADL models for ARINC653 systems. It is fully integrated with OSATE2 and Eclipse.
Getting the sources
You can get the sources of the plug-in on github, see https://github.com/osate/osate2-plugins. On this place, you can check out the ARINC653 specific project: https://github.com/osate/osate2-plugins/tree/develop/org.osate.analysis.arinc653
The following functions are available in the plug-in:
- Analye connections latency
- Check connections
- Suggest refactor ideas
- Check Configuration - Major Frame Correctness
- Check Configuration - Properties of Memory Components
- Check Configuration - Dimensioning of Memory Components
- Check Configuration - Partitions Bindings
- Check Configuration - Partitions Executions
- Check Configuration - Criticality between connected Partitions
- Check Configuration - Definition of Partitions Criticality
- Check Configuration - Separation of Memory into Segments
The menu of the tool is shown in the picture below.
This function report the maximum (worst-case) latency between two communicating partitions. To proceed with this analysis, we can also specify is the communications are major-frame delayed or not. To configure these characteristic, you have to open the Preferences menu item from the ARINC653 function.
Suggest refactor ideas
When designing an architecture, this is really difficult to take into account all architecture criteria and make the best architecture. The design criteria could be related to many domains (cost, performance, etc) and overlap each other. As a result, making performance improvement can have an impact on the cost and vice-versa.
As the system and software architectures are a really important artifact and would have a major impact on overall development, this is worth to identify all potential issue and defect. For that reason, we introduce a function that suggests architecture improvements from an AADL model.
Using AADL model, this function makes suggestion for refactoring the model using the following example criteria:
- Criticality: the plug-in suggests to split partitions that host components classified at different criticality levels. Thus, system designers can lower the certification/testing requirements of some parts of the system, having an impact on the overall development costs.
- Performance: when a partition has more communication connections with partitions located on another module/processor, the plug-in suggests to move the partition on other module. This would improve the overall performance and improve latency/performance of other partitions using the same communication links.
An example of the result of the tool is shown in the picture below.
In partitioned architecture, the latency of a connection is impacted by different factors: if the communications are flushed at the major frame, if the device driver is executed in a partition, etc. For that reason, changing the scheduling order of the partitions or refactor partitions deployment on the different nodes could have a significant impact on the connection latency. For that reason it is important to have a feedback about the latency we could expect on each inter-partition communication.
For that purposes, our analysis plug-in provides the ability to give an estimation of the worst-case communication time for each inter-partition communication considering their deployment aspects and constraints but also the specific operating system behavior (communication flushed at major frame, etc.)
Check connection: criticality Levels Analysis
When designing a system, it might be especially difficult to analyze the impact of one partition to another, especially in terms of criticality. For this reason, we have a function that inspect inter-partition communication and check if there is any communication that involves partitions classified at different levels. For example, a partition at a low criticality level that communicates with another at a higher criticality level. In that case, the partition at a lower criticality level can send bad data or even corrupted data to the higher one.
The Check configurations menu items are functions that checks the correctness of your model regarding configuration best practices. It is implemented as LUTE theorems and report any success or error in the console view of Eclipse, as shown below.
There is the list of configurations items that can be checked from AADL:
- Major Frame Correctness: check that the value of the Major Frame is equal to the sum of all partitions execution slots.
- Properties of Memory Components: the memory components has all the appropriate properties: Byte_Count, etc.
- Dimensioning of Memory Components: check that the size of the memory component bound to a process is correct regarding process requirements (Source_Data_Size, Source_Code_Size, etc.)
- Partitions Bindings: check that each process is bound to a virtual processor and a memory
- Partitions Executions: check that each partition is executed once by the nodule
- Criticality between connected Partitions: check that partitions that are connected share the same criticality level
- Definition of Partitions Criticality: check that each partitions declares a criticality level
- Separation of Memory into Segments: check that the main memory (RAM) is divided into different memory sub-components
Partitioned architecture variability
As we highlight in the previous section, partitioned operating systems may vary in the way they provide their service. For example, some operating system would flush inter-partition communication as soon as a partition send data on a specific channel while other flush all communication at the major frame. The plug-in provides the ability to specify all these variability, so that engineers can validate the behavior or their architecture using the behavior of different operating systems.
The preferences toolbox is shown in the following picture