154 CHAPTER 10. MDE FOR AVIONICS SOFTWARE CONFIGURATION DEVELOPMENT
into well-defined design steps and precisely define the contracts, interactions and interfaces of each step. Individual design steps are then organized into complex workflow-driven model transformation chains, which are closely aligned with the designated development process followed by the func-tion/system provider or airframer. In order to assist the system architect, our framework guarantees that a certain design step can only be started if all prerequisite steps are successfully completed. This fine grain definition capability allows to easily incorporate additional design steps, if required.
The process starts with the definition of a complete PIADL model as the task of the system architect. It can be either manually defined using the (i) external PIADL editor or (ii) derived from a Simulink model, which is a near one-to-one derivation from a limited set of elements. However, as some ARINC and AIDA specific parameters cannot be directly derived from Simulink, the resulting model requires additional clarification from the system architect, which can be defined using the external PIADL editor. For example, a subsystem block in the Simulink model is mapped to a Job in the PIADL, but its modular redundancy value (how many instances of the job are required) is not present in the Simulink model.
The high-level workflow of the PIM-PSM mapping process is depicted in Figure 10.17. It consists of 28 steps organized into 6 separate groups.
10.5.1 Application Group
The group consists of steps to define the resource requirements of the applications and partitions used in a module and create a viable mapping that is compatible with the available resources and dependability requirements.
First, the PIADL and the PD models are imported into the framework. This step also resolves cer-tain dependability attributes defined in the PIADL like redundancy degree of applications and mes-sages (e.g., triple or double modular redundancy for critical applications). As the platform description does not include all information needed for the allocation process and configuration generation, the system architect needs to (i) define the memory requirements and compatibility mapping of the ap-plications and (ii) define new partitions or modify existing ones and define their explicit memory requirements.
Figure 10.12: Partition Creation To demonstrate how these steps are
cap-tured on model level, Figure 10.12 illustrates the low level model elements created for a partition (partitions creation step). Model Elements in or-ange and dashed lines are newly created, while elements in green (and solid references) are al-ready existing in the model. The tags «Inte-gration»and«PD»represent the package of the model element. Partitions are defined/stored in the Platform Description model with separate model elements describing their corresponding memory requirements capturing the size, access
(type) and type attributes. For easier readability (i) attribute types are excluded from the figure and (ii) references and association are depicted by simple lines.
As the final step in the group, all allocations of applications-to-partitions conforming to the de-fined constraints and requirements are computed.
This is done by translating the complete allocation task to a CSP(M) constraint problem as in-troduced in Chapter 8. As all possible solutions are calculated within the requirements, the system
10.5. STEPS OF THE DIANA PIM-PSM MAPPING PROCESS 155
Figure 10.13: Allocated Communication Channels
architect can select a valid allocation and (if required) can take into account additional non-functional requirements that could not be included in the constraint definition.
The automated allocation is discussed in details in Section 10.7.3.1.
10.5.2 Communication Group
The group involves steps in the PIM-PSM Mapping editor that carry out the allocation of inter-partition communication channels and the specification of ports residing on each end of these chan-nels. The allocation is based on the architecture defined in the PIADL model (derived from a Simulink model), the selected application to partition mapping and the redundancy requirements of the appli-cations. Based on this information the allocation algorithm creates the required ARINC 653 ports and connects them.
For example, in case of triple modular redundancy this can result in a large number of additional channels and ports as all input and output communication channels to and from an application needs to be generated for all its redundant instances.
Additionally, the system architect needs to define the ARINC 653 specific parts like (i) the queue length of queuing ports as they cannot be derived directly from the PIADL and the VxWorks specific queuing port protocol mapping (e.g., sender block or receiver discard) to be able to generate the configuration files. Finally, as the ARINC 653 standard has a strict naming convention the framework validates that all naming conventions are kept for the port and channel names. It also support a simple automated naming algorithm to help the system architect generate valid names.
Figure 10.13 depicts a simple example how the allocated channels are visualised. In this case the Data Monitoringapplication allocated over theI/O Processingpartitions uses theTemp. channel to send the temperature value to theRefresh GUIapplication.
10.5.3 Service Inclusion Group
The Service Inclusion group involves steps to define services for the applications. First, the system architect defines, which services can be used by which applications. Within the DIANA project the logbook service was selected to exemplify how middleware services can be defined in a model-driven
156 CHAPTER 10. MDE FOR AVIONICS SOFTWARE CONFIGURATION DEVELOPMENT
(a) AIDA Logbook creation (b) Excerpt of the Health Monitor Table creation
Figure 10.14: Example model segments for the DIANA PIM-PSM mapping process
manner; thus the tool itself developed within the project gives support only for the definition of the AIDA logbook service.
Once the services are selected the system architect define the different logbooks to be used within the system. This includes the specification of their criticality level and thus the number of replicas that must be present in the system, their dedicated size and unique identifier. As the following step the created logbook are mapped to the applications, which uses them and finally the different replicas are allocated to separate modules to meet the required criticality requirements. For example, on one hand for Level D applications it is allowed to host the logbook on the same module as the applications, however, on the other hand for Level A three separate replicas on different modules (even on separate physical hardwares with unique power supplies) are required.
Again as these steps are mainly defined by the system architect the framework gives support mainly for the early validation of the definitions based on the middleware specifications.
Following the notations introduced in Section 10.5.1, Figure 10.14(a) captures how an AIDA log-book with its three separate replicas are instantiated and mapped to theProc Input Tempapplication at the model level.
10.5.4 Health Monitoring Group
The group consists of steps to define the Health Monitoring recovery tables for module, partition and application levels (see in Section 9.1.1.1) along with the different error entities and actions to be carried out. It supports both the standard ARINC 653 specific error code and action declarations and also gives support for the VxWors 653 RTOS action specifications and mode mappings.
All these definitions are done by the system architect by hand. The framework gives support for early validation (e.g., naming conventions, required action definitions etc.) based on the specification of the different tables and the system-specific requirements for health monitoring tables. The defined tables are saved in the PDD as part of the integration model.
For example, Figure 10.14(b) highlights how the different Health Monitors tables are defined and interrelated on the model level for the WxWorks RTOS. The WxWorksHM is the root of the HM Table definition and it contains theSystem,Moduleand separatePartitionHMTables.
10.5. STEPS OF THE DIANA PIM-PSM MAPPING PROCESS 157
10.5.5 AIDA ICD Group
The AIDA ICD group consists of steps related to the description of messages provided and required by the different applications. First, the quantities used within the system are imported from an already defined set (e.g., velocity measured in kilometer per hour or miles per hour) captured in a specific XML file. This is followed by the definition of the platform specific data types. These types can be either elementary types like integer, float, double or composite types such as varriableArray or fixedArray. Usually, types are derived from already available (or defined) ICD types using constraint on their domain.
Parallel to this step, the structure of the messages are defined. This is done in two steps, first the system architect refines the PIM messages into platform specific messages by defining the head and body parts (names) of the message. When the parts are defined their type is defined in the final step of the group by specifying the data types’ of the specified parts of the messages.
Figure 10.15: Definition of the Temp value in ICD Figure 10.15 describes how the Temp PIM
type is refined into theInt1_100PSM represent-ing an integer value with a domain of 1-100. The Int1_100type is based on the predefined 16 bit unsigned integer type from the ICD with ad-ditional constraints over its domain. Based on these PSM types, complex messages are defined following a similar way, where the ICD pro-vides the basic structures like arrays, buffer, etc and the system architect can construct any fur-ther message types based on these basic building blocks.
10.5.6 Artifact Generation Group
Figure 10.16: Example ARINC 653 Module and Vx-Works Application Description configuration Finally, when the prerequisite steps for a
cer-tain code generator is finished the actual textual representation is synthesized by separate dedi-cated code generators. In our case the ICD gen-erator simply serializes the model into its XML representation using the built in support of the Eclipse Modeling Framework. As for the other artifacts we hand-coded the generators using a template based code generator based on graph transformation rules to derive the required for-mats defined by the two platforms and the mid-dleware (described in detail in Section 10.7).
A sample fragment of the generated configuration tables capturing the definition of a communi-cation channel is captured in Figure 10.16.
Additional generated artifacts are depicted in Appendix D describing different configuration de-scriptors for the module operating system, module level health monitoring and the AIDA logbook service.
158 CHAPTER 10. MDE FOR AVIONICS SOFTWARE CONFIGURATION DEVELOPMENT
Figure 10.17: DIANA PIM-PSM Mapping Process