Subsystem and software relationship around autocode

6.5.3.1 Introduction

For the software implementation of the subsystem that develops a functional model, the software development plan is expected to address the relationship between subsystem and software in case of automatic code generation, and in particular to assess:

a. are changes to the subsystem requirements specification function needed, b. who is responsible for model specification,

c. who checks that the model matches the specification, d. who verifies and validates the models,

e. who checks that automatically generated code matches (i) the model and (ii) the specification, f. any associated questions.

The following section introduces how a given organisation may adapt its existing role model in order to provide effective execution of projects involving automatic code generation. The experience given here comes primarily from the development of space application software, in the highly specialized area of AOCS/GNC; therefore this particular subsystem is mentioned.

6.5.3.2 Roles

6.5.3.2.1 Subsystem modelling team responsibility:

This team is responsible for defining/designing the modes and the control laws for realisation of a given mission. This team verifies that the proposed design (for AOCS/GNC) complies with the required performance levels. To this end it develops models and performs simulations proving that the model is robust and meets the requirements. To ensure the completeness of the simulation tests with respect to the designed model, the coverage of the model during tests is checked.

6.5.3.2.2 Software team responsibility:

The software team is in charge of checking that the model can be auto-coded. It proposes the global architecture of models and any standards, rules or modifications allowing the code generation. It is in charge of model configuration (via the code generator tool) and performs code generation. It checks that modelling rules are respected.

The software team verifies that the code generation has not introduced errors at the functional level, by running reference (regression) test cases (provided by the subsystem team). The software team is in charge of integrating the generated software in the rest of software, and generating a single executable file. It verifies the behaviour of the software in the real target environment.

6.5.3.3 Autocoding process

The process is iterative. This means that it is applicable several times for each subsystem iteration. The subsystem iterations are defined e.g. for a subset of functions that can be easily validated independently. For example, an AOCS iteration is associated with an AOCS mode. In the following, the subsystem of choice is the AOCS, but could be any functional chain subsystem expressed with models having autocode capability (e.g. thermal, power)

Step 1: AOCS preliminary design is defined during phase B, which is ended by the AOCS Preliminary Design Review that baseline the AOCS design, and therefore the subsystem functional models.

Elements of the software AOCS Requirements Baseline are produced, including non-functional requirements, requirements which are not part of the model, and potentially the model.

Step 2: At the beginning of the C/D phase the AOCS and software teams can work separately. The software team works first on the global needs analysis and the definition of the software architecture.

The AOCS team refines the preliminary design and enriches the AOCS models according to the modelling standards defined for auto-coding. It is supported by the software team to help the definition of the software architecture and interface of the AOCS models with the rest of the software.

The AOCS team performs the functional validation of the AOCS model. The AOCS “Critical Design Review” is held once all increments are designed and after performance tests.

In this step, there is a co-engineering phase between the AOCS and software teams to evaluate the auto-code-ability of the AOCS model and to complete it with respect to non AOCS requirements such as operability, FDIR, and software constraints.

Step 3: The validation of the AOCS model can lead to modifications that may induce to restart the previous step

Step 4: The software team develops the software that cannot be generated from the models, in a standalone way. The classical unit test, integration tests, validation tests and code coverage are performed.

Step 5a: This is the genuine autocode approach that maximizes the gain of autocode, but does not insure full code coverage. It is acceptable for software that is not of criticality category A. It is also acceptable for software of criticality category A if the code generator is qualified. Once the AOCS needs are validated using simulations at model level (e.g. Simulink), the unit test concept is applied to the model. Model units (elements of the model) are tested. The model structural coverage is measured (tools exist for the most common modelling environments, e.g. Simulink). Then the code is generated automatically and can now proceed to integration.

Step 5b: This (alternative) approach insures full code coverage. It is mandatory for software of criticality category A and B, except if the code generator is qualified at the same level as the generated code (see ECSS-Q-ST-80C 6.2.8.3). In this approach, the code is automatically generated from the functionally validated model. It is then unit tested in a classical way, and its structural coverage starts to be measured.

Step 6: The complete software, whether manually or automatically generated, is integrated and validated. If automatable, the model tests (i.e. unit tests, validation) may be rerun on the modelling environment with the generated code in order to check the code generator. This is not necessary if the code generator is qualified.

After code generation of the software, the subsystem team continues to use the model to execute the performance tests of the sub-system.

The software maintenance is performed at model level in order to ensure the consistency of the modification.

This is illustrated in Figure 6-1.

Figure 6-1: The autocoding process

Classical approach; insure full code coverage; mandatory for cat A/B software (consistent with E40 5.8.3.5.e), except if the code generator is qualifiedas per ECSS-Q-ST-80C 6.2.8.3 the gain of autocode; does not insure full code validation test cases on the generated code on the validation bench.

CDR

6.5.3.4 Impact on the software reviews

6.5.3.4.1 Software SRR (Software System Requirement Review):

This is the classical subsystem Software Requirements Review. At software SRR, the RB part of the autocoded subsystem is available. This includes the information necessary for the software architect to design, in its architecture, the container that will receive the autocode (frequency, execution time, more generally all non-functional requirements affecting the software architecture).

6.5.3.4.2 Software PDR (Preliminary Design Review):

The goal of the review is to come to common agreement on the requirements and architecture. The objects under review are models, interfaces, and other textual requirements (for parts of the SW subsystem that cannot be modelled).

The models represent all the expected functional requirements (for those requirements that can be modelled) and all external interfaces of the subsystem that can be modelled. The model defines the subsystem SW architecture, i.e. what the main components are and how they communicate. At this stage the model is not necessarily ready to generate product code.

At the PDR the part of code to be manually implemented is identified and the handling of the interfaces between manual and generated code is defined. The selection of the tools for automatic code generation and the coding standards are baselined. The modelling standards have been agreed with Subsystem modelling team before their PDR. Simulation on the model may have been performed but is not subject to review.

6.5.3.4.3 Software CDR (Critical Design Review):

The goal is to demonstrate that software is ready for qualification.

The model used to generate code must be fully completed. The model has been validated in the modelling environment. Generated units have been successfully integrated and SW validation performed,