This scenario constitutes a simple case of a horizontal bi-directional model synchronization relation required to perform scheduling analysis. An AADL model is transformed into an MC-DAG (Mixed-Criticality Directed Acyclic Graphs) model used as input to compute static scheduling tables with the MC-DAG tools. Once computed, the AADL model must be updated with these tables so that configuration files can be automatically generated by RAMSES for the targetted Operating System.
In this scenario, a software application for a UAV is used, which consists of two Directed Acyclic Graphs (DAGs) of tasks for respectively controlling the UAV and filming its environment. Some tasks are critical for navigation of the UAV while others are accessory and have therefore a lower criticality level. All these tasks must be properly scheduled on a multi-core processor according to a mixed-criticality model where in case a time failure event occurs for one of the critical tasks (e.g. the task does not meet its deadline), the system is able to switch to a degraded mode where only the critical tasks are executed with an extended deadline to ensure no time failure event occurs anymore.
Case 2 : Model Refinement and Code Generation with RAMSES
The investigators of this proposal are developing the RAMSES (Refinement of AADL Model for the Synthesis of Embedded Systems) framework for automated code generation of embedded systems from AADL models. This is an example of vertical relations between models of different levels of abstraction.
The RAMSES approach consists of selecting a target Operating System (OS) and applying a set of refinement rules to first generate a refined AADL model with a reduced level of abstraction with respect to the targeted OS. From this refined model, code is then generated for the chosen OS.
Case 3 : AADL and FACE Mapping
With this case, we assume that both AADL and FACE (Future Airborne Capability Environment) models can be modified by designers. Therefore, like for the above Mixed-Criticality case study, this is also a bi-directional model synchronization relation between AADL and FACE models. However, we note that the information content of FACE and AADL models is not the same. It is likely that after an initial AADL model has been generated from a FACE model, execution platform information not necessarily represented in FACE may be added to the AADL model. Conversely, the FACE model may include information not represented in the AADL model. Therefore, with this case study we study how to develop model change policy within ACMoM takin into account the ability of tools implementing the synchronization relation to preserve information not represented in each model. This is also an example of ASoT (Authoritative Source of Truth) management.