OSATE-DIM is validated through 2 case studies.
MC-DAG
The Mixed-Criticality Directed Acyclic Graphs (MC-DAG) framework developed by our group computes scheduling tables for AADL systems with mixed-critical tasks. This case study from the MC-DAG benchmark [1] is a system with a multi-core processor and a process. The Process Component has eight threads, each with a different task. There are two System Operation Modes for low-criticality and high-criticality in the case of a failure. The transitions from one Mode to another are relayed through Connections from the Processor to the Process.
The View-Update in this case study is the addition of static scheduling tables for each Thread. Such tables are modeled in AADL using the RAMSES-specific ‘Execution_Slots’ Property,
so that RAMSES can take those into account when generating OS configuration files during code generation. These tables specify for each Thread, its binding to one of the two cores of the processor and its execution start and stop times.
- Overall, there is an addition of nine rich Property Associations, which are not just value-based, but also contain references to other Instance objects.
RAMSES
RAMSES is an AADL-based tool available as an additional OSATE component and developed by our group for the automatic generation of C code for POSIX, ARINC653, and OSEK-compliant Operating Systems (OS). Starting from an Instance model, RAMSES refines the model by adding details for a specific OS platform as selected by the user. From this refined Instance model, analyses can be performed, which are typically more precise given the lower level of abstraction of the model.
In its current version, RAMSES must first create a new Declarative model from of the selected Instance model, to which the OS-specific details are added. A new Instance model is then computed by OSATE from the newly created Declarative model.
Following this, we have used a simple AADL producer-consumer communications module instance model, refined for a Linux-based platform by transforming Port Connections to Shared Data Accesses and by adding several Data Components and RAMSES-specific Properties, as a second case study for OSATE-DIM. The View-Updates in this case consist of
- addition of 41 Data Components to a Process Component, which are shared by two threads.
- The Port Features interfacing the two threads with each other are changed to Data Access kinds.
- New Data Access Connections are also added between the shared Data Components and the Threads.
- The added Data Components have varying numbers of Properties, and the total number of newly added properties is 122.
- the name of the top-System Instance is changed to “refined_model_impl_Instance”
Experimental Test-Suite
We use an example AADL model to illustrate the transformation rules for each kind of View-update.
The example is a simplified version of the sampled-communications example project from RAMSES.
Its AADL instance specification (left part of figure) consists of a system containing a Memory Subcomponent ‘the_mem’, a Processor Subcomponent `the_cpu’, and a Process Subcomponent ‘the_proc’ having two Thread Subcomponents, ‘the_sender’ and ‘the_receiver’ that communicate with each other through a Port Connection.
The Declarative model of sampled-communications is shown on the right part of the figure. Traces from the Component Instances to their Classifiers on the Declarative side are represented as red edges, whereas traces from Component Instances to their Subcomponent definitions on the Declarative side are shown as blue edges.
Component Addition
Example modification (method testExperimentComponentCreation) :
ComponentInstance proc = topSystemInst.getAllComponentInstances(ComponentCategory.PROCESS).get(0);
ComponentInstance viewer = proc.createComponentInstance();
viewer.setName("the_viewer");
viewer.setCategory(ComponentCategory.THREAD);
Component Updation
Update component name:
Example modification (method testExperimentComponentUpdationName) :
Refine component category:
**updates that are not refine-able (i.e., when the original category of the component is not ABSTRACT) cannot be de-instantiated and are reverted
Example modification (method testExperimentComponentUpdationCategory) :
Refine component classifier:
**updates that are not refine-able (i.e., when the new classifier does not extend the original classifier) cannot be de-instantiated and are reverted
Example modification (method testExperimentComponentUpdationClassifier) :
Component Deletion
Example modification (method testExperimentComponentDeletion) :
Feature Addition
Feature Updation
Feature Deletion
Connection Addition
Connection Updation
Connection Deletion
Mode Addition
Mode Updation
Mode Deletion
Mode Transition Addition
Mode Transition Updation
Mode Transition Deletion
Property Addition
Property Updation
Property Deletion
References
[1] Roberto Medina, Étienne Borde, and Laurent Pautet. 2018. Scheduling Multi-periodic Mixed-Criticality DAGs on Multi-core Architectures. In 2018 IEEE Real-Time Systems Symposium. 254–264.