The systems architecture ontology (SAO): an ontology-based design method for cyber – physical systems

Purpose – Managing components ’ resources plays a critical role in the success of systems ’ architectures designed for cyber – physical systems (CPS). Performing the selection of candidate components to pursue a specific application ’ s needs also involves identifying the relationships among architectural components, the network and the physical process, as the system characteristics and properties are related. Design/methodology/approach – Using a Model-Driven Engineering (MDE) approach is a valuable asset therefore. Within this context, the authors present the so-called Systems Architecture Ontology (SAO), which allows the representation of a system architecture (SA), as well as the relationships, characteristics and properties of a CPS application. Findings – SAO uses a common vocabulary inspired by the Architecture Analysis and Design Language (AADL) standard. To demonstrate SAO ’ s applicability, this paper presents its use as an MDE approach combined with ontology-based modeling through the Ontology Web Language (OWL). From OWL models based on SAO, the authors propose a model transformation tool to extract data related to architectural modeling in AADL code, allowing the creation of a components ’ library and a property set model. Besides saving design time by automatically generating many lines of code, such code is less error-prone, that is, without inconsistencies. Originality/value – To illustratethe proposal, theauthors presentacasestudyin the aerospacedomainwith the application of SAO and its transformation tool. As result, a librarycontaining 74 components and a related set of properties are automatically generated to support architectural design and evaluation.


Introduction
A systems' architecture (SA) model is devoted to describing the structure, behavior and views of a given system [1], where the architectural description offers a representation of the components, features and properties of the systems, which could represent an SA. However, managing the components within cyber-physical systems (CPS) that make intensive use of sensors and actuators, probably requiring modifications along its life cycle, is a laborious and error-prone task. Tasks such as identifying the relationships between components, proposal, it allows saving design time by automatically generating many lines of code, also with the understanding that such code is less error-prone, that is, without inconsistencies.
The remainder of this paper is organized as follows. Section 2 presents relevant related works. Section 3 details the proposed SA ontology, also discussing the applied methodology to build it. Section 4 describes the process to transform an OWL model into an AADL model and the tool set designed for this. Section 5 shows an unmanned aerial vehicle (UAV) domain ontology example of alignment with SAO and the respective model transformations. Section 6 presents our conclusions and perspectives on future work.

Related works
Different authors and organizations have proposed ontologies to represent areas and applications that somehow integrate the components of a system's architecture. For example, the IoT-Lite ontology represents Internet of Things (IoT) resources and services [9], covering platform representation and communication. The IEEE-RAS ontology standard was proposed to represent autonomous robots (ROA) [10]. The World Wide Web Consortium (W3C) proposed two ontologies related to sensor networks: the Semantic Sensor Network (SSN) and the Sensor, Observation, Sample and Actuator (SOSA) [11].
However, the aforementioned ontologies do not cover component-related topics in totality, lacking information regarding their implementation, software connection, bus communication and resource allocation, from software to hardware, which is necessary to represent an SA design, highlighting the need to create a new ontology. There are many methodologies devoted to building an ontology [12][13][14][15], and many encourage the reuse of modules and ontologies seeking to maintain a standard, common vocabulary and other benefits cited by W3C [11].
Regarding the practical application of ontologies in the design of CPS, some works evaluate consistency during integration, formalizing the interrelationships between the different views. In [6,16], it is tackled inconsistency in the context of different design processes. Such issue is also covered in [17], which provides reasoning techniques that allow achieving greater understanding of CPS.
Regarding CPS architecture design, MDE approaches and ADLs are used during activities or steps aiming to represent SA. ADL helps to promote mutual communication and allow the early analysis and feasibility testing of architectural design decisions [18]. Thus, developing an ontology for SA development based on ADL helps to represent common concepts, aligning vocabularies and knowledge.
Given the limited expression power of the existing languages to model ontologies, the W3C released, in 2004, a new language called Web Ontology Language (OWL). OWL is a semantic web language to represent relationships and interactions among entities and groups of entities based on a Resource Description Framework (RDF) that describes the conceptual structure of OWL ontologies. OWL 2 extends OWL with a small but useful set of features that have been requested by users, for which effective reasoning algorithms are now available, and which OWL tool developers are willing to support [19]. Furthermore, such a structural specification of OWL 2 provides the foundation for the implementation of tools such as "reasoners," so that other facts can be inferred that are implicitly contained in the ontology.
OWL 2 is a general-purpose modeling language not tied to a specific domain, such as UML and SysML. Usually, in the scientific community, system requirements modeled on UML and SysML sources are used in an OWL transformation model [20][21][22][23]. This is due to the similarity of the structure of languages that are based on RDF metamodels and that can be used in the creation of rules, mappings and extensions or additional elements to become OWL ontology.
Differently from OWL, UML and SysML, domain-specific modeling languages (DSMLs) cover a range of abstraction levels for a particular domain and support conservation and reuse. DSMLs (e.g. AADL) often support automatic source code generation from DSML models.
For instance, AADL is a DSML from Society of Automotive Engineers (SAE) [24] that is intended to offer a unified framework for model-based software systems engineering. AADL can capture static structure and dynamics in a single architecture model and annotates it with information that is relevant to the analyses of characteristics.
AADL models represent SA as a hierarchy of interacting components. In total, AADL provides ten component categories to define software, hardware and composite system components. Software component categories are data, subprogram, thread, thread group and process. Hardware component categories are memory, processor, bus and device. Lastly, the system component is composed of hardware, software or both hardware and software components. In addition, AADL supports the early prediction and analyses of capabilities and operational quality attributes (such as performance, reliability and security) [3] in SA projects.
Behjati et al. [25] provide an overview of an AADL model, representing its main concepts and their relationships, based on the AADL reference manual [3]. These core concepts were elaborated as metamodel abstractions describing a system in terms of their components, interfaces and connectors between the interfaces. Metamodels support the model transformation process, aiding the exchange of OWL data and representation of SA through AADL.
Other MDE-based designs proposed the transformation of models, such as UML-MARTE [26] SysML [4] and SIMULINK [27], to AADL with a focus on data having the same representation in architecture and consistency. In the present work, we show an approach that serves to transform OWL models into AADL models. The transformation process follows the principles of MDE and requires metamodels of source and target models.

Adopted design methodology
This section describes the SAO design, detailing the adopted steps that supported its development and defining the entities that make up our proposal. Such a proposal was inspired by the ontology design methodology guide presented in [15]. It consists of seven steps used in the development of SAO, as further described.
Step 1 focuses on determining the domain and scope of the ontology. Considering the knowledge base provided by ADLs that provide the structure and detailed description of the components and relationships, we define the main nomenclature, concepts and vocabulary used in SAO design. Thereby, starting with a model representing the SA in the AADL language, we define the initial concepts from SA hardware components (devices, processors, memory and buses), software (process and threads) and their interaction (connections and binding).
Step 2 targets the reuse of existing SA ontologies to build a wider SA ontology. Reuse enables object-oriented design, providing the flexibility to structure the ontology in a target domain by adapting the desired module. In this case, we reused the SOSA and SSN with System Capability Module (SCM) ontologies to extend S&A representation with Quantity, Unit, Dimensions and data Types ontology (QUDT), which can be applied to the properties of SA [28].
In Step 3, we integrated the selected ontologies by aligning the modules, entities, terminologies and vocabulary to the outline of the target ontology. Considering that the SA ontology has reference to AADL, its components compose the ontology classes that guide the mapping and alignment.
Afterward, in Step 4, we declared the SAO classes based on the AADL models' structure using the AS5506C standard [24] and reusing imported classes. SAO classes represent the hardware, software and system components of an SA. An important premise when designing SAO is to reuse ontologies aligned with the SAO's domain and its components. In Figure 1, SAO classes are presented. The sao:Sections class represents the contents of sao:ComponentType and sao:ComponentImplementation and includes a set of sao:Features and sao:Properties descriptions. The sao:Features class represents the interface of components. The sao:Properties class represents the characteristics of components and has a relationship with the reuse sao:SystemCapabilityModule class. Another class is sao:Connections, which represents the interconnection between components. sao:Annex, sao:Modes, sao:Flows, sao:Prototypes and sao:extends are classes that support the representation of the content of component types and implementation, which will be presented later. The sao:SOSA class represents the reuse of sensor-and actuator-imported classes that need to be aligned.
With ssn-scm:SystemCapabilityModule, classes are imported from the SSN ontology to represent a set of properties that describe operations, conditions and system properties that have a relationship with the sao:Properties class. Extending the SCM, we include the ComponentProperty subclass, which describes additional characteristics from S&A that cover hardware, software and architecture design presented in a previous work (omitted due blind review process). In Step 5, we defined the objects' properties. From the SAO classes and AADL metamodel structure of relationships, we defined a set of object properties to represent the relationship The systems architecture ontology between the classes of component, implementation and description of content, as shown in Table 1.
According to the ADL model, the components of the architecture can be defined as types and modeled in a structure of sections that can be aggregated as needed by the designer. Each section seeks to detail the specific characteristics and properties reserved for the modeled component. Here The component implementation has sections that are intended to declare how its structure, interactions and interconnections are organized. Thus, sao:Sections, similar to component types such as properties and attachments, has a scope aimed at describing details at the level of implementation and individual of the sao:Subcomponents that comprise it.
In Step 6, we defined the data and value type used in the ontology to represent some kind of data. In this step, the data properties assigned to the data representation classes (domain) and range (type of data) are declared. Usually, data types and values are modeled using a schema definition language to support a wide variety of data representation (i.e. XML Schema Definition language -XSD).
Data and data types are declared following a proposed structure based on AADL. With this structure, there is less effort when aligning the OWL and AADL languages, supporting the model transformation process; an example is shown in Figure 2. The data structure is as follows: declaration of the name of the data propertyin this case, the mass measurement unit qudt:Mass; declaration of the type of class to which it belongs, for example, mass is a subclass of qudt: Weight; declaration of the measurement unit, reusing the QUDT ontology that provides the unit that we will use in this measurement represented with the terminology (g); declaration of the maximum (ValueMax) and minimum (ValueMin) allowed values and data typeconsidering the application, the components must have a mass less than 2000 g and are represented in integer data type:xsd:int. In total, 18 types of data were declared, which can be added in the future depending on the application of the SA and its components.
Lastly, in Step 7, we created a set of individuals to represent the materialization of the components of a CPS architecture in a specific application, which can be used to provide data for models in life cycle projects.
Individuals can represent a generic or precise description of classes. Generic individuals represent some description not related to components but related to the capability, comments or descriptions of the system (e.g. colors, unit of measurement and words). Precise descriptions represent a component type, component implementation, property set, capability and sections, which detail technical specifications. For components and implementation types, we have a set of related classes for representation. Thus, the individual can contain, through object properties assertion, a set of individuals from sections and capabilities types to describe their features and properties.
By completing the steps, the ontology is consolidated and provides a knowledge base for the semantic evaluation of an individual architecture, a physical process that represents the environment and control plant, measurement units and the network used in a specific domain.
It is important to highlight that SAO can be reused in other domains to support the representation of the architecture. For example, the aerospace domain has an area-specific  Ontologies related to SA, that is, representing components of the architecture, can be aligned to SAO in order to expand the representation of the system. Because SAO is based on AADL, OWL models can be used as input in the model transformation process to generate complementary architectural models in AADL to analyze the system's capability.

OWL model transformation to AADL
From the OWL domain model used as the source in the transformation engine, a set of activities are performed for identifying the architecture-related individuals, which lead in the generation of an AADL model package from OWL entities, data and properties that are related to the SA. This requires the mapping and creation of a set of rules and declarations that support the transformation engine presented in this section.
The generated AADL package contains three files, so that it is in accordance with the good practices to create AADL models [29], supporting a modular architecture design. Such files aim to represent: (1) the set of properties that compose measurements and units used by SA; (2) the architecture of the implemented system; and (3) the components library.
The OWL2AADL plugin was developed within this work to support this process. It is available on GitHub [1].
The transformation process requires the OWL Model source to conform to SAO and reuse structure and RDF/XML syntax. Based on the MDE method of M2M transformation, the OWL and the AADL metamodels are used to provide data structure and to create a set of specifications and rules.
In Figure 3, we present the transformation engine flow. The Transformation Specification block defines the mapping and relationships from OWL entities using SAO and reuse structure and the AADL structure model to process a set of Transformation Rules to generate an AADL model as output.
In the Transformation Specification block, OWL entities are defined based on the OWL2 metamodel [19], mapping classes, object properties and data related to the structure of the AADL model and its elements. The Transformation Rules block uses the data provided by Transformation Rules process OWL entities with relationships with AADL components through mapping, as shown in Table 2. The OWL Class is a component related to SA, sections or system capability. Individuals represent component features and properties, depending on the type of object property defined. ObjectProperty is used to composite AADL components, SA implementation and the property set. It also describes the relationship between the classes of the architecture components and the knowledge base.
DataProperties is dedicated to the model measurement objective and units of SAO and has a relationship with the AADL property set file. However, the property set has a distinct declaration structure, which is covered in more detail in the next table. NamedIndividual is related to individual components and properties. In this case, it is only dedicated to individual components as the DataProperties cover properties in property set modeling. From DataRange, we defined the list of components that applies a set of properties. Lastly, AnnotationProperty provides information to the AADL property set, such as metric unit conversion.
AADL models enable architectural assessments and analyses based on the declaration of properties. These properties are modeled in a separate file called the PropertySet, which has a defined structure composed of property type declaration, property constant declaration and property declaration.
Property type defines a type for the values that are acceptable to a property, establishing a name and the set of legal values for a property of this type through a type definition. Property definition provides the name and type of properties used by AADL elements. Property constants are property values that are known by a symbolic name and can be used wherever the value itself is allowed [3].
Thereby, to support the fulfillment of properties in AADL model declaration, we defined a set of seven DataProperties that should be followed as a standard in modeling the data property to SAO property assertions, as shown in Table 3 List of components to which specific property belongs AnnotationProperty A comment that provides information to AADL property set  In Table 4, we summarize the alignment between the OWL data type and basic property type constructors provided by the AADL standard. In this case, OWL data type declarations are defined to support the fulfillment of the model transformation process, following a set of variables to support the construction of the AADL property set and enabling the AADL plugin analyses in the OSATE2 tool.
The transformation rules block is composed of two sequential activities. The first is to transform the OWL file in Java objects related to the OWL structure. In the second activity, these objects were transformed to Java objects related to the AADL model structure through transformation Specification, where objects related to AADL are used as the basis for creating AADL files.
In the first activity, we used a library to process and transform the OWL file into Java objects. Because it is based on XML, the tool uses the standard Java library (available in the org.w3c.dom package) widely used in the development of tools. This library returns a Java object containing the entire contents of the file.
The OWL2AADL tool searches for the node Class; in the sequence DataProperties and ObjectProperty; and, finally, Individual. It is important to follow this order because of the references defined by the OWL2 structure model. For example, an Individual node contains references to one or more owl nodes: Class, DataProperties and ObjectProperty.
The second activity occurs in the conversion of OWL-related objects to AADL-related objects. In this activity, the tool creates a set of files, including a library component, AADL package and property set. After conversion at the Java object level, AADL-related objects are used to guide the writing of AADL files.

Case study
In order to illustrate the SAO application, including the model transformation from OWL to AADL, a case study related to the development of a UAV is presented in this section. Such a UAV design is, in fact, part of a research effort named ProVant. It involves two Brazilian research institutions, the Federal University of Minas Gerais (UFMG) and the Federal University of Santa Catarina (UFSC), in collaboration with the University of Seville (Spain). Since the beginning of ProVant, four aircraft prototypes have been designed. Besides enhancing the flight properties, each new version aims to enhance the problems encountered in the predecessor project. The fourth-generation aircraft is currently under construction, and this study collaborated to refine the draft design (version 4.0) to the one that is in fact being constructed (version 4.1).
This section is organized in two parts. Section 5.1 relates to the application of SAO to develop the OWL model of the Provant 4.0 aircraft. Next, in 5.2, we show the transformation of the OWL model into AADL through the developed OWL2AADL tool.

ProVANT 4.0 OWL model
In order to present more details regarding the representation of the aircraft (mechanical, structural parts), an ontology dedicated to UAVs called drone ontology [30] was reused, which is a knowledge base in the aerospace domain. In this way, it was possible to detail the physical process of CPS, such as the type of mission and application, and the aircraft components (i.e. fuselage, payload, landing and lift system, engine type).
The components that make up the SA were provided by the engineering team and are presented in Table 5. Based on SAO entities, these components were modeled in OWL, detailing their characteristics, properties and relationships with the physical process of the system. Each component has a specific set of properties, which includes maximum and minimum values, and the related units of measurement, which need to be properly defined.
Each component type has a set of technical characteristics provided by their manufacturers (available on data sheet and manuals), which represent its capabilities. These data properties will be fulfilled with the numerical values of each capability of the components of the architecture to be modeled, thus enabling semantic evaluations to be carried out.
After declaring the data properties of the ProVANT 4.0 components, the individual modeling of the components and the system begins. Each created individual contains three definitions field-modeled based on SAO declarations: types, object properties assertions and data properties assertions, as presented in Figure 4. Types define the classes that the components belong to. In this case, ProVANT 4.0 has a list of types to describe generic UAV characteristics, by drone ontology, such as fuselage, UAV category and hardware components (sensors and actuator). Object properties assertions follow the individuals' relationships. The modeling of the individual that represents the ProVANT 4.0 architecture and its components is carried out with the declaration of the object properties assertions of SAO, where each component was previously modeled, also as an individual, and declared in the architecture.
An example of modeling the AXI 2418 brushless motor is shown in Figure 5. This component is classified as an electric motor in drone ontology and a device in SAO. Among   the object properties, hardware characteristics were defined, such as PWM communication port, power consumption properties, period and mass. The data assigned to the properties are presented in the data property assertions. In total, the ontology has 1219 axioms, 696 logical axiom, 129 classes, 133 object property, 34 data property, 86 individuals and 47 annotation property. From the entities of the OWL model, reasoners pallet of the Proteg e tool were applied to analyze inconsistencies and inferences between the components of the architecture, physical process and quality attributes such as performance, behavior, traceability and support to designers for identifying impacts in architectural components change.

Model transformation: OWL to AADL
After modeling, in OWL, the data properties and individual that represent the ProVant systems and their components, the designer uses the OWL2AADL transformation tool developed in this work.
The tool is an OSATE2 plugin that performs the process of transforming OWL models to AADL, as presented in Section 4. The process is based on MDE concepts, where, from the metamodels of the input (OWL) and output (AADL), a set of transformation rules proposed in the transformation engine are performed. The tool reads the OWL file and processes the relationship with OWL entities to AADL elements, generating two AADL model files containing the property set and the architectural model. These two generated files contain the minimum AADL structure necessary for modeling the system and carrying out evaluations and analysis in OSATE2.
The generated SAO AADL property set file is based on OWL data properties declared with the definitions presented in Table 3 from the transformation engine process. The SAO AADL property set file follows the AADL structure declaration, which defines the data type, unit of measure, maximum and minimum values and capability name. A part of the SAO property set file is shown in Listing 1. In total, 42 lines of code were automatically generated, enabling the modeling of properties of AADL components of the ProVant SA.
The second file generated by the tool is the OWL2AADL package, which contains the AADL components of the architecture, resulting from the transformation process of the OWL individuals. OWL model input provide 83 individuals, including the ProVANT architecture, component features and library candidate input. In total, the OWL2AADL output file creates 74 AADL components, represented in 409 automatically generated command lines.
The number of AADL components generated in the transformation was smaller than the number of OWL individuals because there were individuals not directly related to the types of components. In total, nine individuals representing the section type were used to build the component features. Regarding outstanding space limitations, in Listing 2, we show some AADL components that make up the Provant 4.0 SA, generated using the OWL2AADL tool. The systems architecture ontology After the OWL2AADL tool generates the AADL models and property set from individuals' representation, it is possible to open these files in OSATE2 and thus perform instances and analyses of the architecture through the development of plugins. This allows us to carry out multiple analyses related to the impact of quality attributes and characteristics.

Conclusions and future work
In this work, we proposed an SAO, aimed at representing semantically the SA of CPS, providing terminologies, vocabulary and concepts and identifying the relationships between hardware, software and system components, with a focus on implementation. SAO can be reused in other domain ontologies to represent the details of the SA. We conducted a study of