Model-based software engineering, Partitioning of Software according its criticality, UML, Development Process Automation

Transcription

1 ERTS² Extended Abstract Paper Submission Title: Modeling ARINC-653 Systems in UML Author: Andreas Korff Affiliation: Atego Systems GmbH, Major-Hirst-Str. 11, D Wolfsburg, Germany Abstract: Within DO178-B/C projects, the certification effort for the software under development can be drastically reduced if the different software components can be divided into appropriate partitions, which can be handled separately. The ARINC 653 specification deals with this aim, in combination with its RTOS definitions. Modern model-based software development can cover software design taking RTOS integrations into account, but ARINC 653 compliancy needs additional views, like partitions and ARINC 653 resources. We will present an approach how to integrate UML-based development with ARINC 653 views and configuration file generation compatible with major RTOS implementations. Key Words: Model-based software engineering, Partitioning of Software according its criticality, UML, Development Process Automation Full Paper: When developing and maintaining safety-critical avionics software, organizations face the problem that although the complexity of the systems and therefore the software is raising from project to project, the development time and effort to be spent is even getting lower and lower. Systems and software development based on federated architectures, as seen in figure 1, cannot cope with that situation. There is just one central controller, which is linked to all sensors and effectors, therefore an error on one component effects the whole system. Fig. 1: Class Diagram showing a typical federated architecture

2 Every change affecting components in use might cause a different timing, so scheduling is affected and consequences must be checked carefully. This increases the work needed to tackle obsolescence and reduces to chance for re-using any part of the system. In order to overcome high maintenance costs and low re-use potential for avionics software, we should have a closer look on the typical layers in the central controller. On the very outside, an interface layer to the physical world is a common pattern, allowing to control the real-world sensors and effectors. Before processing the data is possible, a second layer for data formatting is usual as well. The third layer is then responsible to do the calculations and data processing. These three layers are shown in figure 2, together with their mapped representative, appropriate layers in the Stanag 4626/EN 4660 (ASAAC) definition. The uppermost Data Processing Layer in the federated architectures does not need to be responsible for scheduling anymore, since this is done in the operating system layer. On the other hand, the data formatting is not handled normally on OS level; therefore the application has to do this accordingly. The physical interface layer maps perfectly on the module support layer. Federated Architecture Data Processing Layer {maps for logic} {maps for scheduling} Stanag 4626/EN 4660 (ASAAC) Application Layer Data Formating Layer {maps} Operating System Layer Physical Interface Lacer {maps} Module Support Layer Fig. 2: Federated Layers and their appropriate layer in ASAAC Based on these three layers for application, OS and module support, we can now define components in the application layer, as seen in figure 3, for e.g. one hardware node. In the application layer, the different system functions are split into independent, possibly re-usable components, like Autopilot, Navigation, or Telemetry. The components do not interact directly; instead they are using standardized inter-component communication means, provided by the OS Layer. Accessing the node hardware is done using dedicated components on the Module Support Layer. Since it is necessary to support a network topology of more than just one hardware node, the OS Layer is also responsible to manage the activity on each node in addition to the communication use cases on one node. We could visualize this by displaying multiple Open Architecture Hardware Nodes, with the OS Layers being connected.

3 This all results in an architecture, which consists of de-coupled application partition, which can be certified independently, if the underlying OS Layer, respectively its implementation supports and guarantees these rules. Fig. 3: Open Architecture Hardware Node showing partitioned application components With the ARINC 653 (Avionics Application Standard Software Interface) standard, organizations implementing Integrated Modular Avionics (IMA) architectures, as described above, gain benefits in several areas: 1. Due to the partitioning of the system, the overall system robustness can be increased or maintained. 2. Typically system applications have assigned different safety integrity levels (SIL), which corresponds to their certification effort. Being able to group the applications into different ARINC 653 partitions reflecting their safety integrity level, this drastically reduces the certification effort to the minimum for each of these levels. 3. The re-certification effort is also drastically reduced to the partitions affected. 4. There is a standardized API to de-couple application code from the RTOS in use, called APEX (APplication EXecutive). APEX also offers standardized communication mechanisms. A standard is always only as good as its implementation. Several RTOS suppliers, like Wind River or SYSGO, offer support for ARINC 653, all including an APEX API for the different programming languages supported and in use, like C or Ada. In addition, there is the need in ARINC 653 to define the relevant structural elements like application partitions, the communication paths and health monitoring definitions. All of these configurations are made textually using XML. On the other hand, UML-based development is commonly and successfully used for software-centric projects, also in the Aerospace domain. Here, more and more projects are using model-based development for exactly the same reasons like for using ARINC 653: Scalability, traceability, maintainability, communication, and the ability to check completeness and correctness. Most of the projects are combining both levels of abstraction, on one hand the UML model for designing the overall structure and to link the different perspectives like structure, behavior and non-functional constraints, and on the other hand the code level for implementation details. Model-to-text transformations exist to connect these two levels, like the Automatic Code Synchronizer in Artisan Studio, which also can take the RTOS used into account. Using the UML as a basis with its generic extensibility using profiles, we can bring this all together in one model. In order to avoid the sometimes very cumbersome and error-prone definition of the XML files for the ARINC 653 configuration, the idea is now to

4 1. Define a UML profile according a meta-model, which reflects all the elements and their associations for ARINC 653 configurations. This can be done e.g. by the tool vendor, who offers this standard extension 2. Stereotype UML diagrams to support the views needed to model the necessary elements for ARINC 653, as described here 3. Define a model-to text transformation, which generates the appropriate XML files for the IDE in use A UML profile consists of a cohesive set of stereotypes and tag definitions, which extend ordinary UML metatypes, like class, operation, or role. Normally, these extended model elements, like for instance a class being stereotyped with «Module» representing an ARINC 653 Module, can only be shown on diagrams which display the appropriate meta-type, class. Some UML tools allow defining stereotypes on UML diagram types, including the toolbar commands or menu entries when using the diagram. Figure 5 shows a specific diagram toolbar for an ARINC 653 Configuration Diagram, which is defined on top of a UML Composite Structure Diagram. Fig. 4: A Toolbar for modelling an ARINC 653 Configuration Diagram Extending the UML Composite Structure Diagrams with relevant tags and stereotypes as shown in figure 5, the software designer now can define the system and software structure for an ARINC 653 project, by giving him a graphical means to model everything around the ARINC-specific configuration of partitions and communication elements. The configuration diagram shows one node, defined as <<Module>>, which contains three partitions as stereotyped parts. According the normal DO178-B/C definitions, they are named with the relevant criticality levels DAL A to C. As an example, we have modeled the navigation application on partition DAL_B and its controlled communication as queuing ports connecting this application with the Autopilot application on the DAL_C partition. They interchange the position information using a controlled channel. «Module» Open Architecture Hardware NodeModule «SystemHMTable» systemhm : «PartitionHMTable» parthm : «ModuleHMTable» modulehm : «Partition Part» DAL_A Engine Management «Partition Part» DAL_B Navigation «Process Part» UpdatePos «Channel» positionchannel «QueuingPort» PosData «Partition Part» DAL_C «QueuingPort» PosData Autopilot Telemetry «Process Part» UpdateDisplays «SharedLibrary» vxsyslib : Fig. 5: An ARINC 653 Configuration Diagram shows partitions, applications and processes

5 It is also important to note that in addition of the automatic application of the ARINC 653 stereotypes, the diagram tools allow to apply the ARINC 653-specific semantics, so e.g. only compatible ports can be connected to define the communication between ARINC 653 partitions. Extending the typical modeling steps with profilespecific functionality can also automate many modeling actions the user normally would have to manually. In order to be effective, the tool support should do as much construction work automatically and then help the user filling out the automatically generated templates, e.g. indicating a graphical modeling error like in figure Fig. 6: A typical ARINC configuration dialog for indicating an user error In parallel to the model-based development of the software structure and behavior expressed in the appropriate programming- language, thus generating C or Ada form the UML class and state model, there are additional gaps to fill, like generating the ARINC 653 configuration XML files and the relevant initialization code in the used programming language. Both tasks can be fulfilled by changing the transformation rules from the model to code or text files. Since generators like the Artisan Studio Automatic Code Synchronizer can analyze every aspect of the model, like e.g. the elements defined using the ARINC 653 Profile, and then generate files based on rules defined in the Artisan Studio Transformation Development Kit, the full set of code and configuration files can be automatically and continuously generated from the amended UML model. As an small example of the many XML configuration files being generated, the navigation application configuration is shown here, indicating e.g. the modeled queuing port: <?xml version="1.0" encoding="utf-8"?> <ApplicationDescription xmlns=" xmlns:xi=" xmlns:xsi=" xsi:schemalocation=""> <MemorySize MemorySizeBss="0x10000" MemorySizeData="0x10000" MemorySizePersistentBss="0x10000" MemorySizePersistentData="0x10000" MemorySizeRoData="0x10000" MemorySizeText="0x10000"> </MemorySize> <Ports> <QueuingPort Direction="SOURCE" MessageSize="256" Name="PosData" Protocol="NOT_APPLICABLE" QueueLength="32"> </QueuingPort> </Ports> </ApplicationDescription> As this generation process for both the XML code and the programming language code is working in the background, the modeler can add the implementation details in his standard code IDE used for the chosen RTOS implementation for ARINC 653. This results in an automatic and coherent update of any structural change of the ARINC 653 system, single-sourced by the amended UML model. For the navigation application, the applicable startup code is shown below: #include "Navigation.h" #include "UpdatePos.h"

6 PROCESS_ID_TYPE UpdatePos_id; QUEUING_PORT_ID_TYPE PosData_id; void usrappinit() { #ifdef USER_APPL_INIT USER_APPL_INIT; /* for backwards compatibility */ #endif PROCESS_ATTRIBUTE_TYPE UpdatePos_attr; static const char UpdatePos_name[] = "UpdatePos"; RETURN_CODE_TYPE rc; int i; for(i = 0; i <= MAX_NAME_LENGTH-1 && UpdatePos_name[i]; i++) UpdatePos_attr.NAME[i] = UpdatePos_name[i]; UpdatePos_attr.NAME[i] = '\0'; UpdatePos_attr.ENTRY_POINT = (SYSTEM_ADDRESS_TYPE)entrypoint; UpdatePos_attr.STACK_SIZE = 0x800; UpdatePos_attr.BASE_PRIORITY = 10; UpdatePos_attr.PERIOD = INFINITE_TIME_VALUE; UpdatePos_attr.TIME_CAPACITY = INFINITE_TIME_VALUE; UpdatePos_attr.DEADLINE = HARD; CREATE_PROCESS(&UpdatePos_attr, &UpdatePos_id, &rc); CREATE_QUEUING_PORT("PosData", 256, 32, SOURCE, FIFO, &PosData_id, &rc); START(UpdatePos_id, &rc); SET_PARTITION_MODE(NORMAL, &rc); STOP_SELF(); } return; Conclusion We have shown that the model-based approach for IMA systems can be very effective, when there is a possibility to express in addition to the normal software views in UML also the partition configurations showing modules, applications, processes and all communication and structural means defined for safety-critical airborne software. Leveraging the UML extensibility and tool extension capabilities, the user can be both guided and manual, repetitive work can be automatically done. If the code generation functionality is extensible as well, the relevant configuration XML files can be generated from the same model as the normal application code, which is amended as well by the necessary startup code for the OSes supporting ARINC 653.