**5. Fault-tolerant mobile robot proof-of-concept**

Following the naive example above, an ontology-driven reconfiguration capability for mobile robots has been explored in the Metacontrol for Robot Operating System (MROS) project<sup>6</sup> . In this implementation, the robot's mission is to move to a certain point. During the mission, several contingencies may occur. In this case, we contemplate the internal contingency cases of (i) laser rangefinder failure and (ii) low battery. Additionally, the mission has some operational requirements associated in terms of performance, safety, and energy consumption that the robot must ensure during the navigation.

The assurance of the operational requirements along with the contingency handling is governed by a knowledge base structured on description logics and exerted by a reasoner. The key of this approach is the usage of the general modeling framework presented in Section 2.3, TOMASys. The TOMASys ontology is particularized with two sets of individuals: the navigation-domain ontology and an application-specific ontology. We use a modular approach in the construction of the ontology to be capable of reusing a part of the non-specific knowledge in any navigation application in mobile robotics. The ontologies are instantiated for runtime use as a knowledge base composed of three OWL 2 [26] files.

The TOMASys metamodel is used to depict structure and behavior with an explicit representation of the objectives of the system as well as the components required to realize them. The system concepts provided by this metamodel are divided into two main groups:

• The static knowledge is stored in Functions and Function Designs. The Function element allows the definition of abstract Objectives for the system to complete the mission. The Function Design element stores all the design

<sup>6</sup> https://robmosys.eu/mros/

An example of this case is the use of different navigation sensors in a mobile robot. Suppose we have an autonomous robot with laser and ultrasound sensors to navigate. An initial objective may be to reach a point as fast as possible. According to the final design of the robot, that requirement would be specified with a specifi-

The laser is a device with a high refresh rate so the robot can navigate safely at higher velocities. If the robot enters a room with glass walls, the laser is not reliable. If the robot detects through the reasoning that the environmental conditions are not suitable for the laser and triggers a reconfiguration to use the ultrasound sensor, the robot can keep its operation to fulfill the mission. However, as the design has changed, the requirements that can be fulfilled are not the same. In this case, as the ultrasound sensor has a shorter range, the maximum velocity of the robot shall be significantly less to keep a safe operational profile. Once the robot has traversed that glass room, the laser can be re-activated so the requirements must change again to

This is a naive example of how a system engineering knowledge base can improve a navigation task. However, real-world missions are composed of complexorchestrated tasks, for instance, the operation of a waiter-robot which must serve a drink, or a miner-robot that must obtain a certain mineral. In this case, that knowl-

edge can be further exploited with deep reasoning to perform adaptation at

Following the naive example above, an ontology-driven reconfiguration capability for mobile robots has been explored in the Metacontrol for Robot Operating

certain point. During the mission, several contingencies may occur. In this case, we contemplate the internal contingency cases of (i) laser rangefinder failure and (ii) low battery. Additionally, the mission has some operational requirements associated in terms of performance, safety, and energy consumption that the robot must

The assurance of the operational requirements along with the contingency handling is governed by a knowledge base structured on description logics and exerted by a reasoner. The key of this approach is the usage of the general modeling framework presented in Section 2.3, TOMASys. The TOMASys ontology is particu-

application-specific ontology. We use a modular approach in the construction of the ontology to be capable of reusing a part of the non-specific knowledge in any navigation application in mobile robotics. The ontologies are instantiated for run-

The TOMASys metamodel is used to depict structure and behavior with an explicit representation of the objectives of the system as well as the components required to realize them. The system concepts provided by this metamodel are

• The static knowledge is stored in Functions and Function Designs. The Function element allows the definition of abstract Objectives for the system to complete the mission. The Function Design element stores all the design

larized with two sets of individuals: the navigation-domain ontology and an

time use as a knowledge base composed of three OWL 2 [26] files.

. In this implementation, the robot's mission is to move to a

cation of a targeted velocity value.

*Robotics Software Design and Engineering*

achieve the maximum performance available.

different tasks and several stages of the system life cycle.

**5. Fault-tolerant mobile robot proof-of-concept**

System (MROS) project<sup>6</sup>

ensure during the navigation.

divided into two main groups:

<sup>6</sup> https://robmosys.eu/mros/

**78**

alternatives the system engineer has thought as possible to fulfill a certain Function.


As it was previously mentioned, the knowledge base is completed with two sets of individuals. The navigation-domain file contains instances of widely-used navigation sensors such as ultrasound, laser, RGBD cameras, etc., and other important elements in autonomous robots such as the battery. These elements are instances of the TOMASys class Component. Besides, popular Quality Attributes are defined such as energy, safety, and performance.

The application-specific knowledge base is made of all the Function Designs, these are the design alternatives to perform navigation. Other elements are the instance of an Objective, the instance of a Function Grounding, this is the Function Design in use, and the Quality Attributes relative to them. Each Function Design has a Quality Attribute estimation in safety and energy, which is calculated for the Function Grounding. This calculated Quality Attribute value is compared with the non-functional requirements (NFR) defined for the Objective. The NFRs are the Quality Attributes required for the specific mission.

#### **5.1 Run-time reconfiguration for fault-tolerance**

To use the knowledge base at run-time, it is written in a machine-readable format using the Web Ontology Language (OWL). A descriptive logic (DL) reasoner uses it during the system operation to evaluate the robot's functioning. Once an Objective is defined, and it is linked to the Function that solves it, a Function Grounding is selected according to the mission requirements and the Component availability. In the MROS proof-of-concept, two possible classes of contingencies are addressed: component fault and mission requirements non-fulfillment.

Each Component has a *required by* relationship with the Function Design that makes use of it. If a Component is malfunctioning, those Function Designs that use it becomes unavailable. **Figure 1** depicts the main relationships contained in the knowledge base. The two components considered, laser and battery, are required for all Function Designs except one. In case of laser failure, the Function Design degraded mode should be selected. Likewise, in the case of a low battery, the Function Design energy saving mode should be selected. This is implicitly shown in the figure, as there are no links between those Function Design individuals and the corresponding Component individual.

The ontology also includes some rules using the Semantic Web Rule Language (SWRL) to perform functional diagnosis. This is done by asserting the information

When the system needs adaptation because the mission (Objective) is in error according to rule no. 2, a selection of a design alternative is required. In this case, rule no. 3 is applied to determine the solution available in terms of components. An equivalent rule in terms of Quality Attributes and NFRs is used to select the design compliant with the mission requirements. If there are several Function

Metacontroller, selects the Function Design with higher estimated performance. In this case, each Function Design represent a system mode. For instance, the normal mode uses the laser to navigate at maximum velocity levels in environments with few obstacles but not crowded. The degraded mode, uses an RGBD camera instead of a laser to navigate, as the refresh rate of this device is considerably less than the laser, the velocity is reduced to keep navigation with safety. By contrast, the energy-saving mode is a very safe and slow implementation to reduce at maximum the battery consumption, impacting the duration of the mission, and there-

The ontology implementation has been evaluated in a complete robotic application, a patrolling corridors mission. While the robot performs the patrol, contingencies such as the laser error described previously. The robot used is a TurtleBot2 composed of a Kobuki platform RPLidar A2 laser and an Orbec Astra RGBD camera. The experiments consisted of simulating a laser error at a random instant. These data were corrupted by generating realistic data as if something was blocking the laser, or if there was a misalignment, maybe due to a hit or a fall of the robot. This was done by publishing scan messages with erroneous data (a vector of 0's) in the gazebo plugin topic. **Figure 2** depicts the simulation used to develop the reasoner to implement the ontology-driven reconfiguration. The output from the reasoner once the laser is malfunctioning and the

The main experiment carried measures the recovery time for a laser failure using ontology-driven reconfiguration. After 50 iterations of the experiment, the time required is 1.995 s with a standard deviation of 0.478. Without it, the estimated recovery time for this failure is about 300 s (indeed tied to system maintenance). Furthermore, another testbed has been used to prove the ontology reusability along with the reconfiguration performance. In this case, we have used a simulation of an unmanned underwater vehicle performing exploration in a flooded mine [27].

*Simulation of robot patrolling with navigation and localization system; in red, the button to inject laser failure.*

Designs available, the module in charge of the reconfiguration, called

*Using Ontologies in Autonomous Robots Engineering DOI: http://dx.doi.org/10.5772/intechopen.97357*

robot with the navigation mode to degraded is shown in **Figure 3**.

fore, the performance.

**Figure 2.**

**81**

#### **Figure 1.**

*Main individuals and relationships of the proof-of-concept knowledge base. The Objective o\_navigate is fulfilled by the Function Grounding fg\_normal\_mode, this Function Grounding is a realization of the Function Design f\_normal\_mode which solves the Function f\_navigate. This Function is required as is the one that solves the Objective. Component required for this Function Design are laser and battery. Among all the possible Function Design, the one that does not require the laser if it becomes unavailable is f\_degraded\_mode. Additionally, Quality Attributes values relative to the non-functional requirements (NFRs) of the Objective are depicted for the Quality Attributes of safety and energy.*

about the status of the Components that compose the system, the design in use to solve a function (Function Grounding), and the status of the Objective.

There are three sets of rules that: (i) set the Objective in error if the objective requirements, NFR Quality Attributes, are not met; (ii) set an Function Grounding in error if a Component in use is in error; and (iii) propagate Function Grounding error to the Objective. Lastly, there are some additional rules regarding the storage in a log file of the Function Grounding that have been in error and the status of a Function Design realisability depending on the status of the Components. For instance, if the laser is in error, the only Function Design with realisability with a true value will be *f\_degraded\_mode* according to **Figure 1**. **Table 1** shows three example SWRL rules used in this proof-of-concept.

*Rule no.1 tomasys:Component(?c) tomasys:c\_status(?c, false) mros:requiredBy(?c, ?fd) tomasys:typeFD(?fg, ?fd) tomasys:FunctionGrounding(?fg)* ! *tomasys:fg\_status(?fg, INTERNAL\_ERROR)*

If a Component has a status in false (in error), and that component is *required by* a Function Design with the same *type* as the Function Design in use, Function Grounding, then that Function Grounding status is set as *INTERNAL ERROR*.

*Rule no.2 tomasys:FunctionGrounding(?fg) tomasys:fg\_status(?fg, INTERNAL\_ERROR) tomasys:solvesO(? fg, ?o) tomasys:Objective(?o)* ! *tomasys:o\_status(?o, INTERNAL\_ERROR)*

If a Function Grounding has a status in *INTERNAL ERROR*, and that Function Grounding *solves* an Objective, then that Objective status is set as *INTERNAL ERROR*.

*Rule no.3 tomasys:Component(?c) tomasys:c\_status(?c, false) mros:requiredBy(?c, ?fd)* ! *tomasys: fd\_realisability(?fd, false)*

If a Component has a status in false (in error), and that Component is *required by* a Function Design then that *realisability* is set to *false*.

#### **Table 1.**

*SWRL rules for proof-of-concept implementation. The first one sets the Function Grounding in error if it uses a faulty Component, the second one sets the Objective in error if the Function Grounding is in error and the third one marks as unreachable the Function Design that require unavailable Components.*

#### *Using Ontologies in Autonomous Robots Engineering DOI: http://dx.doi.org/10.5772/intechopen.97357*

When the system needs adaptation because the mission (Objective) is in error according to rule no. 2, a selection of a design alternative is required. In this case, rule no. 3 is applied to determine the solution available in terms of components. An equivalent rule in terms of Quality Attributes and NFRs is used to select the design compliant with the mission requirements. If there are several Function Designs available, the module in charge of the reconfiguration, called Metacontroller, selects the Function Design with higher estimated performance.

In this case, each Function Design represent a system mode. For instance, the normal mode uses the laser to navigate at maximum velocity levels in environments with few obstacles but not crowded. The degraded mode, uses an RGBD camera instead of a laser to navigate, as the refresh rate of this device is considerably less than the laser, the velocity is reduced to keep navigation with safety. By contrast, the energy-saving mode is a very safe and slow implementation to reduce at maximum the battery consumption, impacting the duration of the mission, and therefore, the performance.

The ontology implementation has been evaluated in a complete robotic application, a patrolling corridors mission. While the robot performs the patrol, contingencies such as the laser error described previously. The robot used is a TurtleBot2 composed of a Kobuki platform RPLidar A2 laser and an Orbec Astra RGBD camera. The experiments consisted of simulating a laser error at a random instant. These data were corrupted by generating realistic data as if something was blocking the laser, or if there was a misalignment, maybe due to a hit or a fall of the robot. This was done by publishing scan messages with erroneous data (a vector of 0's) in the gazebo plugin topic. **Figure 2** depicts the simulation used to develop the reasoner to implement the ontology-driven reconfiguration. The output from the reasoner once the laser is malfunctioning and the robot with the navigation mode to degraded is shown in **Figure 3**.

The main experiment carried measures the recovery time for a laser failure using ontology-driven reconfiguration. After 50 iterations of the experiment, the time required is 1.995 s with a standard deviation of 0.478. Without it, the estimated recovery time for this failure is about 300 s (indeed tied to system maintenance).

Furthermore, another testbed has been used to prove the ontology reusability along with the reconfiguration performance. In this case, we have used a simulation of an unmanned underwater vehicle performing exploration in a flooded mine [27].

**Figure 2.** *Simulation of robot patrolling with navigation and localization system; in red, the button to inject laser failure.*

about the status of the Components that compose the system, the design in use to

*Main individuals and relationships of the proof-of-concept knowledge base. The Objective o\_navigate is fulfilled by the Function Grounding fg\_normal\_mode, this Function Grounding is a realization of the Function Design f\_normal\_mode which solves the Function f\_navigate. This Function is required as is the one that solves the Objective. Component required for this Function Design are laser and battery. Among all the possible Function Design, the one that does not require the laser if it becomes unavailable is f\_degraded\_mode. Additionally, Quality Attributes values relative to the non-functional requirements (NFRs) of the Objective are depicted for*

There are three sets of rules that: (i) set the Objective in error if the objective requirements, NFR Quality Attributes, are not met; (ii) set an Function Ground-

Grounding error to the Objective. Lastly, there are some additional rules regarding the storage in a log file of the Function Grounding that have been in error and the status of a Function Design realisability depending on the status of the Components. For instance, if the laser is in error, the only Function Design with realisability with a true value will be *f\_degraded\_mode* according to **Figure 1**. **Table 1** shows three example SWRL rules used in this proof-of-concept.

*Rule no.1 tomasys:Component(?c) tomasys:c\_status(?c, false) mros:requiredBy(?c, ?fd) tomasys:typeFD(?fg,*

If a Component has a status in false (in error), and that component is *required by* a Function Design with the same *type* as the Function Design in use, Function Grounding, then that Function Grounding

*Rule no.2 tomasys:FunctionGrounding(?fg) tomasys:fg\_status(?fg, INTERNAL\_ERROR) tomasys:solvesO(?*

If a Function Grounding has a status in *INTERNAL ERROR*, and that Function Grounding *solves* an

If a Component has a status in false (in error), and that Component is *required by* a Function Design

*SWRL rules for proof-of-concept implementation. The first one sets the Function Grounding in error if it uses a faulty Component, the second one sets the Objective in error if the Function Grounding is in error and the third*

*Rule no.3 tomasys:Component(?c) tomasys:c\_status(?c, false) mros:requiredBy(?c, ?fd)* ! *tomasys:*

*?fd) tomasys:FunctionGrounding(?fg)* ! *tomasys:fg\_status(?fg, INTERNAL\_ERROR)*

*fg, ?o) tomasys:Objective(?o)* ! *tomasys:o\_status(?o, INTERNAL\_ERROR)*

*one marks as unreachable the Function Design that require unavailable Components.*

Objective, then that Objective status is set as *INTERNAL ERROR*.

solve a function (Function Grounding), and the status of the Objective.

**Figure 1.**

*the Quality Attributes of safety and energy.*

*Robotics Software Design and Engineering*

status is set as *INTERNAL ERROR*.

*fd\_realisability(?fd, false)*

**Table 1.**

**80**

then that *realisability* is set to *false*.

ing in error if a Component in use is in error; and (iii) propagate Function

complexity when working on small modules integrated into a whole ontology. This conceptual decomposition and complexity reduction can be extrapolated to the

The use of a knowledge base that makes explicit the requirements and the design decisions on the system, provides systems engineering knowledge that can be leveraged at the whole life cycle. The explicitness of mission-oriented concepts makes it easier for the developer at the verification phase to understand possible fault sources and integration problems. The trend in systems engineering towards model-based approaches is rooted in the formal verification capability that models provide at all stages (esp. at early stages where the costs of re-engineering are much lower). At the early stages of the model, complexity is lower and formal analyses may be more exhaustive and effective. In the deployment phase—as shown in our proof-of-concept—ontologies may be used as fault-tolerance assets. The use of ontologies to reason about the state of the mission and the architectural components in use in general terms, provide a common framework to decouple reconfiguration actions from the particular implementation. This separation of concerns allows for a strong reduction in the complexity of the fault-tolerant mechanisms by both (i) the localized nature of the fault-tolerant mechanisms; and (ii) the possibility of reusing general tested assets such as TOMASys

and some of the more general knowledge bases (as the ones presented here8

earlier but spans all classes of multi-agent collaboration in fielded systems.

especially when they are heterogeneous. For example, the shared information between an unmanned aerial vehicle (UAV) and an unmanned ground vehicle (UGV) may encounter incompatibilities just in the coordinate systems they use, as the UGV does not take into account the vertical axis. Moreover, robots may have different capabilities, a UAV may be able to map the environment whilst the UGV

The use of ontologies in the construction of formal knowledge bases provides a common understanding within a domain. The encoding of ontologies in machinereadable formats such as OWL allows a truthful integration when sharing information between different agents and/or tools. This integration obviously includes the possibility of collaboration between different types of systems in a group mission. This collaboration is not limited to the activities in the systems life cycle as described

An example of this is the enabling of collaborative work between fleets of robots,

The same occurs when the system includes a human as an external operator or supervisor, the system must exchange information to ensure collaborative work. Usually, the combination of data is done implicitly by the system designers. However, using ontologies for formal integration of all the different perspectives of a system of systems with an explicit *conceptualization* provides a robust and trustworthy method for sharing information that affects the way humans interact and

As said before, a formal definition of system concepts can be used for better

formal analysis along the whole life cycle. This upstream analysis implies a

<sup>8</sup> Available at: https://github.com/MROS-RobMoSys-ITP/mros\_ontology

, especially in

).

conceptualization that underlies all system engineering processes<sup>7</sup>

systems-of-systems contexts, [29].

*Using Ontologies in Autonomous Robots Engineering DOI: http://dx.doi.org/10.5772/intechopen.97357*

**6.2 Implications on collaborative systems**

may have an arm to interact with it.

**6.3 Implications on risk management**

<sup>7</sup> See for example http://www.sebok.org.

**83**

collaborate with machines.

#### **Figure 3.**

*Console from the reasoner ROS2 node to implement the ontology-driven reconfiguration; in red the component status of the laser as 'FALSE', malfunctioning and the navigation mode required, the Function Grounding 'DEGRADED MODE'.*

With this proof-of-concept, we have implemented a fault-adaptive subsystem in general terms to ensure mission requirements and face component faults. This approach provides a general and reusable asset for systems in which there are design alternatives in terms of behavior and/or components. This approach aptly realizes the vision of using ontologies for building knowledge bases to decouple the mission-oriented system operation core from the reconfiguration needed to overcome disturbances or failures. Moreover, with this experimental setting, we have shown evidence of the advantages of automatic reconfiguration through ontological architectures for reducing the recovery time for laser contingencies.

#### **6. Systemic implications of ontologies**

As stated in Section 2, ontologies provide a variety of tools to define a system in terms of concepts and the relationships among them. Besides, given their formal nature, they can be included in the system as an explicit source of knowledge to improve its run-time operation.

Ontologies can be treated as a sub-system itself, that may be designed following the systems engineering principles of modularity, scalability, and reusability. The proof-of-concept presented here (Section 5), is an example of the use of ontologies to augment the autonomy level of a robot, increasing its dependability by improving mission assurance. In this proof-of-concept system ontologies are components of the deployed system.

However, the use of ontologies as part of autonomous systems engineering processes goes well beyond this [18], because they can have a strong impact on the many processes of the systems life cycle [28]. In this section, we analyze three classes of impacts: (i) impacts on complexity; (ii) impacts on collaboration; and (iii) impacts on risk management.

#### **6.1 Implications on complexity**

Section 2 summarised some of the benefits of modularity in ontologies. The key feature of the modular approach is the reduction obtained in the ontology

complexity when working on small modules integrated into a whole ontology. This conceptual decomposition and complexity reduction can be extrapolated to the conceptualization that underlies all system engineering processes<sup>7</sup> , especially in systems-of-systems contexts, [29].

The use of a knowledge base that makes explicit the requirements and the design decisions on the system, provides systems engineering knowledge that can be leveraged at the whole life cycle. The explicitness of mission-oriented concepts makes it easier for the developer at the verification phase to understand possible fault sources and integration problems. The trend in systems engineering towards model-based approaches is rooted in the formal verification capability that models provide at all stages (esp. at early stages where the costs of re-engineering are much lower). At the early stages of the model, complexity is lower and formal analyses may be more exhaustive and effective.

In the deployment phase—as shown in our proof-of-concept—ontologies may be used as fault-tolerance assets. The use of ontologies to reason about the state of the mission and the architectural components in use in general terms, provide a common framework to decouple reconfiguration actions from the particular implementation. This separation of concerns allows for a strong reduction in the complexity of the fault-tolerant mechanisms by both (i) the localized nature of the fault-tolerant mechanisms; and (ii) the possibility of reusing general tested assets such as TOMASys and some of the more general knowledge bases (as the ones presented here8 ).

#### **6.2 Implications on collaborative systems**

The use of ontologies in the construction of formal knowledge bases provides a common understanding within a domain. The encoding of ontologies in machinereadable formats such as OWL allows a truthful integration when sharing information between different agents and/or tools. This integration obviously includes the possibility of collaboration between different types of systems in a group mission. This collaboration is not limited to the activities in the systems life cycle as described earlier but spans all classes of multi-agent collaboration in fielded systems.

An example of this is the enabling of collaborative work between fleets of robots, especially when they are heterogeneous. For example, the shared information between an unmanned aerial vehicle (UAV) and an unmanned ground vehicle (UGV) may encounter incompatibilities just in the coordinate systems they use, as the UGV does not take into account the vertical axis. Moreover, robots may have different capabilities, a UAV may be able to map the environment whilst the UGV may have an arm to interact with it.

The same occurs when the system includes a human as an external operator or supervisor, the system must exchange information to ensure collaborative work. Usually, the combination of data is done implicitly by the system designers. However, using ontologies for formal integration of all the different perspectives of a system of systems with an explicit *conceptualization* provides a robust and trustworthy method for sharing information that affects the way humans interact and collaborate with machines.

#### **6.3 Implications on risk management**

As said before, a formal definition of system concepts can be used for better formal analysis along the whole life cycle. This upstream analysis implies a

With this proof-of-concept, we have implemented a fault-adaptive subsystem in

*Console from the reasoner ROS2 node to implement the ontology-driven reconfiguration; in red the component status of the laser as 'FALSE', malfunctioning and the navigation mode required, the Function Grounding*

As stated in Section 2, ontologies provide a variety of tools to define a system in terms of concepts and the relationships among them. Besides, given their formal nature, they can be included in the system as an explicit source of knowledge to

Ontologies can be treated as a sub-system itself, that may be designed following the systems engineering principles of modularity, scalability, and reusability. The proof-of-concept presented here (Section 5), is an example of the use of ontologies to augment the autonomy level of a robot, increasing its dependability by improving mission assurance. In this proof-of-concept system ontologies are components

However, the use of ontologies as part of autonomous systems engineering processes goes well beyond this [18], because they can have a strong impact on the many processes of the systems life cycle [28]. In this section, we analyze three classes of impacts: (i) impacts on complexity; (ii) impacts on collaboration; and (iii)

Section 2 summarised some of the benefits of modularity in ontologies. The key

feature of the modular approach is the reduction obtained in the ontology

general terms to ensure mission requirements and face component faults. This approach provides a general and reusable asset for systems in which there are design alternatives in terms of behavior and/or components. This approach aptly realizes the vision of using ontologies for building knowledge bases to decouple the mission-oriented system operation core from the reconfiguration needed to overcome disturbances or failures. Moreover, with this experimental setting, we have shown evidence of the advantages of automatic reconfiguration through ontological

architectures for reducing the recovery time for laser contingencies.

**6. Systemic implications of ontologies**

improve its run-time operation.

of the deployed system.

**82**

**Figure 3.**

*'DEGRADED MODE'.*

*Robotics Software Design and Engineering*

impacts on risk management.

**6.1 Implications on complexity**

<sup>7</sup> See for example http://www.sebok.org.

<sup>8</sup> Available at: https://github.com/MROS-RobMoSys-ITP/mros\_ontology

reduction of the probability of faults during system operation but it also includes the possibility of better diagnostic features. having explicit knowledge on relationships among system entities allows the system to trace the source of faults and take action in the implicated parts.

Besides, the system may adapt itself as the case presented in Section 5 to reduce damage or can even take preventive action based on deep reasoning. When the system is able to adapt to overcome problems derived from environmental changes or malfunctioning components, the system becomes more autonomous and trustworthy.

Design decisions have always associated risks. Usually, the final design is commonly the solution with less risk in the context where the system is deployed. The use of ontologies provides a tool for risk management as design decisions may be justified in the knowledge base. Furthermore, this information can be used at runtime to apply the most suitable solutions if the operational environment changes.

In the proof-of-concept presented here, quality attributes are used to select among design alternatives. When risk augments because of not meeting the security standards of the mission, other designs can be used. This may affect the performance of the mission but ensures its fulfillment. The system engineer must coordinate adequately those quality attributes to ensure a trade-off between performance and security. In this context, risk ceases to be a collateral effect of system design and operation to become a first-level citizen in the explicit design of the system.
