MDDA: A Model Driven Avionics Data Architecture

2017 3rd International Conference on Computer Science and Mechanical Automation (CSMA 2017) ISBN: 978-1-60595-506-3

MDDA: A Model-Driven Avionics Data Architecture

Pei HONG

, Yuan SONG

, Yue-Yuan JIN

and Ruo-Nan RAO

1

China Aeronautical Radio Electronics Research Institute, Shanghai, China

2

School of Software, Shanghai Jiao Tong University, Shanghai, China

a

[email protected], [email protected], [email protected],

d

[email protected], *Corresponding author

Keywords: Avionics software system, Model-driven method, Avionics data architecture.

Abstract. Large-scale complex avionics software system which is developed by different team

together may exist message semantic ambiguity, lack of information and other issues during the system integration. This paper analyzes the key architecture attributes of avionics software system architecture, i.e. portability and interoperability, and proposes a Model-Driven Avionics Data Architecture (MDDA) based on the standardized software component interoperation message transmission interface. MDDA models the message transformed between avionics software components through the standardization of message transmission interface in the platform-independent ontology semantics level, measurement semantics level and platform-related message data type level respectively. OCL is used to constrain and verify the data model, and codes of platform-related message data type model are generated to ensure that the data used in interoperate is semantically and grammatically consistent. In order to realize the reuse of the basic model elements in the ontology and measurement semantic model, this paper further puts forward the management mechanism of these basic model elements. According to MDDA this paper designs and implements a distributed MDDA environment system (MDDAES), which is based on cloud infrastructure and aimed multi-team coordination, including four tools. Finally, requirements of practical avionics project are extracted and a verification case is developed. The verification shows that MDDAES is feasible and effective.

Introduction

Large-scale complex avionics software systems typically integrate multiple task-level software components and subsystems, which are often developed independently by multiple teams across agencies. In the system integration, these software components in the interoperability process may exist semantic ambiguity, measurement mismatch and lack of information and other issues. The reasons for these problems are the tight coupling of the data transmission interface between the interoperable software components, and the lack of specification and common understanding of the message data transmitted by the parties involved in component interoperability. Therefore, based on the analysis of the attributes of portable and interoperable key architecture of large-scale complex avionics software system, this paper proposes a Model-Driven [1] Avionics Data Architecture (MDDA), controlling data model and its message code Generation to provides a canonical approach to interoperability between task-level software components.

(OCL) [3] to constrain the data model of the relevant software components. For the validated data Model, using the message data type model to generate code to ensure that the interoperability of data in the semantics and grammatical consistency. In order to ensure the semantic consistency of data model elements and the consistency of measurement, this paper proposes a mechanism for unified management of basic elements such as ontology and measurement in MDDA data model. Different teams can re-develop the data model of software components independently using these basic elements, thus ensuring the consistency of its data model semantics.

The second chapter of this paper analyzes the problem of message transmission in multi-team development process. Chapter 3 presents the detailed design of MDDA. Chapter 4 describes the prototype system of avionics data architecture implementation environment (MDDAS) based on MDDA in detail. Chapter 5 presents a validation case developed using MDDAS based on the needs extracted from the avionics actual project. Chapter 6 describes some of the relevant work. The last chapter summarizes the full text.

Problem Analysis

Portability and interoperability are important architectural attributes of avionics software systems and are a major concern in system integration. A reference architecture model of Avionics software system based on the Software Computing Environment (SCE) is shown in Fig 1.

Figure 1. A reference architecture of avionics software system based on SCE.

compatible with a variety of transmission Protocol and so on. Development environment is composed by agile development process, data center and application center. Based on the capabilities services provided by SCE, avionics applications are integrated with task-level software components developed by different teams, and these SCE-based software components have cross-platform portability. The interoperability of software components emphasizes the ability to communicate and share data between programs across platforms and programming languages. The SCE normalized transport interface solves the tight coupling problem of interfaces that transmit data, but the parties involved in interoperability are unaware of the specification of transmission data and lack common understanding.

Model-Driven Avionics Data Architecture Design

MOF-based Hierarchical Data Modeling Method. Meta Object Facility (MOF) is called

meta-object facility or meta-object mechanism, which is the theoretical basis of OMG organization's Model-Driven method. The core of the MOF is a hierarchical metadata framework that allows you to add new types of metadata as needed to provide a scalable metadata management approach. The transmission of messages in the avionics system is usually very complex. If the data is directly modeled on the transmission message, the difficulty and complexity of the modeling are increased, and the reusability of the model is low. Therefore, the key to data modeling lies in the separation of modeling concerns. Based on MOF, this paper proposes to model the exchange data from three levels: ontology semantic model, measurement semantic model and message data type model, as shown in Fig 2.

Figure 2. Hierarchical data model of MDDA.

The elements of Ontology Semantic Model (OSM) include indivisible ontologies, entities made up of ontologies, and models used to define concepts and relationships. Among them, the ontology refers to the concept of observable atoms, that is, the most basic terminology of the field of navigation, where the observable refers to the physical world through the measurement. Entities are made up of ontologies and other entities.

Measurement Semantic Model (MSM) is the refinement of OSM, that is, adding details to the ontology and the entity, such as units, measurement system, and the range of values. The entities in the MSM are explicitly modeled according to the relevant entities in the OSM. An OSM can be implemented as multiple MSMs.

The first two models are platform independent, and the Message Data Type Model (MTM) is related to the specific platform. The base elements in the MSM are implemented in the MTM as physical data types. This physical data type can directly correspond to the data type in the code. The same MSM can be implemented as multiple MTMs to support the implementation of different platforms.

Consistent Verification of MDDA Model Based on OCL. OCL is a formal, ambiguous language that defines the model constraints well, and because it is declarative, it does not change the content of the model. In a multi-team development process, different components are provided by different component providers, and the system integrator needs to validate the data model provided by the component provider when integrating the system. There are two aspects about verification. First, you need to verify that the data model conforms to the specification. The data model is ultimately to generate the code, then the data model must conform to the specification and correct. Second, the data model of the message between the interoperable components should be consistent, which requires consistency verification of the data model. In this paper, OCL is used to define the model specification to verify the PSCM provided by the component provider.

The process of data model validation is to validate each constraint defined by the data model according to the OCL file. The specifications defined in MDDA include that each element in the data model has a unique Id, and that the corresponding entities of the different hierarchical models should keep the structure consistent. The OCL-validated data model as a validated model generates message code for use by system integrators.

Message Code Generation Based on The Message Data Type Model. Data modeling can

eventually produce a model of XML data format for message data. The model is used as the input of the Message Code Generation Tool, and eventually some message code can be generated. The code generation tool mainly includes three parts: model scanner, code template and data type mapping file. First, the model scanner will analyze the input model file, figuring out elements, sub-elements and their dependencies contained in the model file and generating a topology map. And then according to the topology, some data in template code will be replaced with classes name and their member variables, and generate an intermediate code. The intermediate code is then scanned, and the type of the code in the model code is converted to the type of the corresponding code according to the external pre-defined type-mapping file [4, 5, 6], thus completing the generation of the object code. The mechanism of message code generation used in this paper is shown in Fig 3.

Figure 3. Mechanism of Message code generation.

Code generation tools using model-based design and automated code generation technology, can be a good guarantee of software consistency and the code will be uniformly optimized by the automation tool. Software features can be quickly modified after the automatic generation of code without the need for complex processes, saving a lot of time and labor costs.

The Management Mechanism of Basic Elements in Reusable Semantic Model. In order to

Figure 4. Management mechanism of basic elements.

The entire RSM management system consists of the RSM library and user data model library. Ordinary users can obtain the basic model elements in the RSM library and upload their own data models through the cloud service. CCB members are responsible for the management of RSM libraries.

Design and Implementation of MDDAES

MDDAES Prototype Architecture. The prototype of the Avionics Data Architecture

Environment includes data model modeling tool environment, model validation tool, reusable semantic base element management system, and portable unit message code generation tool. MDDAES prototype structure is shown in Fig 5.

Figure 5. Prototype Architecture of MDDAES.

There are three types of roles in the whole prototype system. Data model developers use Data Model Modeling Tools and RSM libraries to establish data models, and then use Model Validation Tool to verify the data model. CCB members manage RSM libraries. The prototype system uses the cloud service to access the RSM library, and in order to facilitate the management, provides the RSM management system WEB portal. The system integrator uses the message code generation tool to generate the portable message code from the data model and use it when the system is integrated.

MDDA Data Modeling Tool. MDDA hierarchical modeling mechanism is different from

ordinary UML [9] modeling methods, so we need to modify a common UML modeling tools. In this paper, the prototype system aims at the mainstream commercial modeling tool (EA), which implementing a UML prototype (XMI format) for defining three-level modeling elements, and it is imported into EA to realize the avionics data model modeling environment. The UML Profile defines the elements and rules used in OSM, MSM, MTM modeling, such as ontology, entity, measurement system, unit, relationship, and so on, for users to establish a visual data model.

MDDA Model Validation Tool. The process of data model validation is to validate each data

model according to the OCL file. Importing a well-defined OCL file into EA can verify the consistency of the data model with the constraint specification and the data model between the interoperable components. The OCL file in prototype system mainly includes the following rules:

(1) Each element in the data model has a unique name;

(2) The platform entity combination hierarchy must be consistent with that of the logical entity. (3) The platform value type must correspond to the logical measurement and information element;

Reusable Semantic Model Management System. The reusable semantic model management system provides the modeler with the underlying model elements, while supporting supports CCB to manage reusable base elements. The reusable semantic model management system provides a distributed version management mechanism for RSM libraries by using open source software such as zookeeper and GitLab.

(1) RSM Management System Portal.

RSM Manage System Portal is a Web portal that provides a REST service interface for users. Users include model developers and CCBs that use RSM.

(2) RSM library management module.

RSM management module to achieve the RSM library management, RSM library is a distributed version control system based on the establishment of GitLab. This distributed version control mechanism provides more flexible and efficient file management.

(3) RSM element change monitoring and notification module.

The module is developed based on the distributed coordination service Zookeeper, and uses watch mechanism of Zookeeper to achieve the RSM element changes in the monitoring and notification function, which promptly notify the CCB members of the RSM library change request.

Component Message Code Generation Tool. The code generation tool allows users to access

from the web side. By uploading an XMI format model file, we can generate the corresponding component message code. At the same time, a development tool based on the Eclipse message code generation tool is provided to users, so they can select the user data model library data model to generate the message code to the corresponding working directory, to facilitate the use of system integrators.

Verification Case

This paper extracts the actual project requirements of avionics, and verifies the correctness of the MDDA and the feasibility of MDDAES through the transmission data from two components developed by the SCE standard interface. The two components are GPS and PFD (Primary Flight Display), respectively, transferring GPS data through the transmission service capability interface, as shown in Fig 6.

According to the overall MDDA architecture proposed in Chapter 3, we first modeled the GPS data. In the OSM model, the position can be modeled as an entity, consisting of Id and Position, where Id is the ontology, and Position is the entity, both of which are the basic elements in the RSM library.

MSM of GPS data is based on the OSM, adding Position measurement, as shown in Fig 7.

Figure 6. Demo of GPS and PFD.

After MTM is established, the corresponding physical data type is implemented for each ontology of GPS, and MTM of GPS is shown in Fig 8.

Figure 8. MTM of GPS data.

After the completion of the three-tier data model, we can export the XML format data model for OCL validation. The above model uses the model validation tool in MDDAES to verify compliance. Message code can be generated from MTM by Message code generation tool. The generated message code can be compiled with the corresponding component code and can be run. The above case verifies the correctness of the MDDA and the availability of the MDDAES prototype system.

Related Work

Since 1900s, the integrated avionics system with open architecture has attracted wide attention. The United States SAE AS4893-5 GOA put forward the general open architecture GOA [7] (Generic Open Architecture). It classified the avionics required interface, specified the structure of software and hardware and interface, but only gave the requirements of level and interface division without specific interface definition. ASAAC [8], ARINC653 [9] architecture divided the model of avionics system architecture in different levels, and each has advantages and disadvantages. But the data transmission of the three architectures was based on traditional message communication, and did not consider the semantic concept of data transmission.

The Future Airborne Capability Environment (FACE) strategy [10] proposed by the Open Group divides the architecture into multiple segments, where the segment responsible for message transmission is called transport service segment. The FACE reference specification defines the message specifications and semantic information in the transport service segment, and proposes the concept of the shared data model SDM [11] to manage the model elements.

FACE embodies the development direction of the open avionics software system architecture, but it is combined with business strategy. Based on some of the technical ideas of FACE data architecture, this paper proposes a distributed RSM management mechanism based on cloud service, which lays a technical foundation for further integration into artificial intelligence technology in the future.

Summary

Acknowledgement

This paper is supported by the pre-research project (Project No. 16GFZ-KG02-112) which is

cooperated by China Aeronautical Radio Electronics Research Institute and Shanghai Jiaotong

University.

References

[1] OMG. Model Driven Architecture [M]// Model driven architecture. Wiley, 2003:298-302.

[2] Group O M. Meta Object Facility (MOF) Core Specification Version 2.0[M].2016.

[3] Warmer J. The Object Constraint Language [J]. 2003.

[4] Object Management Group. OMG IDL Syntax and Semantics, February 2001.

[5] OMG IDL Language Mapping for C, Version 1.0; retrieved from: www.omg.org/spec/C/1.0/.

[6] OMG IDL Language Mapping for C++, Version 1.3; retrieved from:

www.omg.org/spec/CPP/1.3/.

[7] SAE AS4893 Generic Open Architecture (GOA) Framework, Chuck Roark, IEEE Explore Conference: Digital Avionics Systems Conference, 1996, 15th AIAA/IEEE.

[8] Analysis of ASAAC Avionics Standards, Wang Yun-sheng, Chen Ying, Telecommunication Engineering, Vol. 47, No. 5, Oct. 2007.

[9] https://en.wikipedia.org/wiki/ARINC_653.

[10] C145-Technical Standard for Future Airborne Capability Environment (FACE™) Edition 2.1.