Next activities integrate the implementation of the HW/SW co-design tool support:
- System-Level Performance Tool Implementation extending AADS tool for AADL simulation and
- Study/ASSERT Toolset Integration implementing the ASSERT Model Transformation (AMT) tool and integrating
the tool-chain of the case-study.
- Model Transformation Analysis to evaluate the compliance of the implemented toolset with the ASSERT process.
System-Level Performance Tool Implementation
A first version of AADS-T has been produced, which is compliant with Ravenscar Computational Model (RCM).
The AADL Simulator for TASTE (AADS-T) combined with the use of the SCoPE tool bears the responsibility for the performance and
power estimation. Its flexibility enables AADS-T to support different processors. In the scope of HWSWCO study,
the simulation is performed on a LEON2 processor.
AADS-T allows modelling a subset of AADL including the Behavioural Annex for purposes of implementation and simulation.
This AADL specification must contain a minimum functionality described by means of some AADL properties in order
to enable a proper simulation of the model.
The AADL model will be parsed by AADS-T and a model defined with POSIX/C++ and XML will be obtained.
This model will be simulated in order to check if the AADL constraints are fulfilled. As the design process
advances and the real functionality are attached to the software components using the corresponding source code,
the value of these properties will be refined. These refined properties will be added to the AADL model and a
new model will be generated by AADS-T to check if the constraints are still fulfilled.
Study/ASSERT Toolset Integration
AMT tool is developed as an Eclipse plug-in integrated with OSATE tool for AADL analysis.
This tool is responsible for managing the System Model and generating the necessary inputs to
the ASSERT tool chain. The main functionalities are the following:
- Obtain the Partition View from the System Model (Logic and Platform Views).
- Derive the hardware and software Data Models from the System Data Model.
- Transform the AADL System Model into models compatible with the ASSERT
model views (e.g., ASSERT Data, Functional, Interface and Deployment Views)
- Load the ASSERT Concurrency View required by AADS-T describing the full set of platform components.
The partition scheme provided by AMT follows a software centric approach. The selected allocation scheme is invalid
whether performance metrics do not fulfil system requirements or any service deadline is missed. Then, a re-allocation
AMT offers a user-friendly interface that guides the designer during the HW/SW co-design hiding the complexity of
this process. The only inputs required are the ASSERT Data and Interface Views, as well as the System Platform View.
Model Transformation Analysis
The objective of this task is the assessment of compliance of the implemented toolset with the ASSERT process. A secondary objective
is to provide feedback on toolset integration.
The main assessment criteria are the ASSERT principles: separation of concerns, automatic code generation and
- The ASSERT Model Transformation (AMT) tool. Next points are stressed:
- Transformation from Logic/Platform Views to Partition View. This process is compliant with
ASSERT principles. It must be only highlighted that the consistency between the Logic/Platform and Partition
views is not automatically preserved.
- Transformation from Partitioned View to Concurrency View. A correspondence between AADS-T and
ASSERT properties has been established, but there are some AADS-T properties that are not supported by
ASSERT. These properties shall be preserved in the AADL code for the ASSERT model views. AMT shall check the
consistency between ASSERT and AADS-T properties.
- The role and place of WCET and schedulability analysis tools in the process should be made explicit.
- AADS-T is used to perform the transformation of Concurrency View to SCoPE. The approach of implementing
the software parts of the concurrency model using C/C++ and a subset of the POSIX API is in accordance with the ASSERT
process principles. Just next two issues have been pointed out:
- Property preservation between the SCoPE analysis model and the system implementation should be analysed more
- Implementation of protected objects. The generation of protected object code by AADS-T should be made
compliant with the Ravenscar model, following similar patterns as in the ASSERT code generation process.