(mostly).

Reliability.mediawiki

@@ -25,7 +25,7 @@ Fault tolerance —both hardware and software— is achieved through some kind o
 
 == Design decisions ==
 
-Reliability building block goal is to improve the reliability aspects of the universAAL platform. Therefore the reliability building block is a vertical layer cross over all layers of universAAL, especially in the Middleware. This can be done by dealing with to major challenges of reliability and enhance the system efficiency. The first action point, the creation of a framework to diagnose the system behaviour by detecting the faults that might occur during the systems operation, and take decisions to overcome such cases. Taking into consideration the existing components of the Middleware, the following components will be reused in the Diagnosis Framework: Context Events, Context Bus and the Situation Reasoner [https://github.com/universAAL/context/wiki| (see Context Group wikipages for more details)]. The Diagnosis Framework, should not create further effort on the operational load of the platform or interrupt other services. The Middleware has a message based communication.Hence, fault detection mechanisms is also using message classification algorithms in order to categorize messages and differentiate all message types interacting in the platform. The diagnosis framework uses a knowledge base of rules that determine the behaviour of the system and define possible solutions. This knowledge base has to be fed continuously with new knowledge and cases to be able to decide in more and more use cases. A Fault injection framework has been implemented to create a high effort testing scenarios for a number of nodes in an AAL space, after the end of this check, a file of feedback results can be used in the knowledge base that is used in the Diagnosis Framework. The Fault Injection Framework in its final version will be fully independent bundle from the Middleware. This will also give universAAL administrators the ability to test the functionality of any uAAL space remotely. The third bundle in the Reliability building block is the Time Triggered patch, this patch is giving the users of universAAL platform the possibility to have an advantage of using a time triggered communication in there uAAL spaces where many reliability aspects are taken already into consideration in the infrastructure used in such communication (e.g. global time synchronization, reliable communication of critical events in the system).
+Reliability building block goal is to improve the reliability aspects of the universAAL platform. Therefore the reliability building block is a vertical layer cross over all layers of universAAL, especially in the Middleware. This can be done by dealing with to major challenges of reliability and enhance the system efficiency. The first action point, the creation of a framework to diagnose the system behaviour by detecting the faults that might occur during the systems operation, and take decisions to overcome such cases. Taking into consideration the existing components of the Middleware, the following components will be reused in the Diagnosis Framework: Context Events, Context Bus and the Situation Reasoner [https://github.com/universAAL/context/wiki| (see Context Group wikipages for more details)]. The Diagnosis Framework, should not create further effort on the operational load of the platform or interrupt other services. The Middleware has a message based communication.Hence, fault detection mechanisms is also using message classification algorithms in order to categorize messages and differentiate all message types interacting in the platform. The diagnosis framework uses a knowledge base of rules that determine the behaviour of the system and define possible solutions. This knowledge base has to be fed continuously with new knowledge and cases to be able to decide in more and more use cases. A Fault injection framework has been implemented to create a high effort testing scenarios for a number of nodes in an uSpace, after the end of this check, a file of feedback results can be used in the knowledge base that is used in the Diagnosis Framework. The Fault Injection Framework in its final version will be fully independent bundle from the Middleware. This will also give universAAL administrators the ability to test the functionality of any uuSpace remotely. The third bundle in the Reliability building block is the Time Triggered patch, this patch is giving the users of universAAL platform the possibility to have an advantage of using a time triggered communication in there uuSpaces where many reliability aspects are taken already into consideration in the infrastructure used in such communication (e.g. global time synchronization, reliable communication of critical events in the system).
 
 ==Artefact #1 : Failure Diagnosis Module in universAAL==
 
@@ -254,37 +254,37 @@ c.Implementing an interface for non-driver software
 
 {| border="1" style="cellspacing=0; bordercolor=gray; align=left; valign=top;"
 ! align="left" bgcolor="#DDDDDD" | FCR
-! align="left" bgcolor="#DDDDDD" | AAL Space Gateway
+! align="left" bgcolor="#DDDDDD" | uSpace Gateway
 |-
 |  Rationale
-|Failure to an AAL Space gateway leads to intra and inter-AAL Space bridging mechanism failure and failure to one gateway is contained within it
+|Failure to an uSpace gateway leads to intra and inter-uSpace bridging mechanism failure and failure to one gateway is contained within it
 |-
 |  Input
-|•Incoming request from a remote user (includes another AAL Space)to start and or publish its service and or service request
+|•Incoming request from a remote user (includes another uSpace)to start and or publish its service and or service request
 •Message from output bus
 |-
 |  Output
-|•Authenticated or denied request to the remote user (includes another AAL Space) and or service provider
-•A communication channel between the remote user (AAL Space) and the current AAL Space
+|•Authenticated or denied request to the remote user (includes another uSpace) and or service provider
+•A communication channel between the remote user (uSpace) and the current uSpace
 
 •Message to input bus
 |-
 |  Service
-|•Manages the activities among the Space Federation (intra-AAL Space) or inside the same space (inter-AAL Space)
-•Acts as an IO handler within an AAL Space
+|•Manages the activities among the Space Federation (intra-uSpace) or inside the same space (inter-uSpace)
+•Acts as an IO handler within an uSpace
 
 •Provides certain communication service to other IO handlers
 •Provides a mechanism to check the trustworthiness (authentication/deny request)
 
 •Enable intra-space communications
 
-•Log the AAL Space activities. 
+•Log the uSpace activities. 
 |-
 |  Failure Modes
-|•Omission failure: An example scenario for this Omission failure is as follows. A remote device tries to connect to the AAL Space through the AAL Space Gateway.  The gateway is not responding to the incoming request for the remote device to join the AAL Space. Another scenario would be if the gateway is omitting the messages that it received from the AAL Space output bus and it should pass those messages to the remote user (includes another AAL Space)
-•Babbling idiot: an example scenario for this Babbling Idiot failure is as follows. The faulty AAL Space Gateway is constantly sending high priority messages to the AAL Space (specifically in the buses(Input bus))
+|•Omission failure: An example scenario for this Omission failure is as follows. A remote device tries to connect to the uSpace through the uSpace Gateway.  The gateway is not responding to the incoming request for the remote device to join the uSpace. Another scenario would be if the gateway is omitting the messages that it received from the uSpace output bus and it should pass those messages to the remote user (includes another uSpace)
+•Babbling idiot: an example scenario for this Babbling Idiot failure is as follows. The faulty uSpace Gateway is constantly sending high priority messages to the uSpace (specifically in the buses(Input bus))
 
-•Value failure: an example scenario for this failure is as follows. A remote trustworthy user (including another AAL Space) tries to join the current AAL Space using the AAL Space Gateway, but the gateway is denying the remote connection
+•Value failure: an example scenario for this failure is as follows. A remote trustworthy user (including another uSpace) tries to join the current uSpace using the uSpace Gateway, but the gateway is denying the remote connection
 
 |}
 
@@ -832,7 +832,7 @@ At the nodes side, a script is required in order to execute some essential funct
 ==Artefact #4 : Time Triggered Ethernet Extension Module ==
 
 === Blackbox Description ===
-uAAL environment contains large variety of embedded devices that need to communicate with each other to achieve a specific AAL service. The delivered AAL services differ in the degree of impact on the  end user, i.e. safety-critical services that deals with user’s health and emergency systems in a uAAL space should be correctly delivered to achieve its targets of high reliability, consequently the different devices that cooperate to deliver such services should support real-time communication and fault-tolerance mechanism to provide a reliable service. Real-time communication means that it is not enough for the network artifact to receive correct response in value domain but also this response should be correct in time domain. 
+uAAL environment contains large variety of embedded devices that need to communicate with each other to achieve a specific AAL service. The delivered AAL services differ in the degree of impact on the  end user, i.e. safety-critical services that deals with user’s health and emergency systems in a uuSpace should be correctly delivered to achieve its targets of high reliability, consequently the different devices that cooperate to deliver such services should support real-time communication and fault-tolerance mechanism to provide a reliable service. Real-time communication means that it is not enough for the network artifact to receive correct response in value domain but also this response should be correct in time domain. 
 
 According to the mentioned facts above , dealing with AAL environments mean dealing with different scenarios with different technical requirements regarding real-time communication. Consequently, different communication networks, protocols, and services could be used to cover all of these requirements. Here, TTEthernet comes to reduce the gab and combine the networks with different criticality into one network. Time-triggered services inspired by Time-Triggered Protocol <ref> The time-triggered architecture. Kopetz, H., and Bauer, G. s.l. : IEEE Special Issue on Modeling and Design of Embedded., 2003.</ref> with Ethernet flavor and standard IEEE 802.3 Ethernet protocol are combined in one Ethernet network. Time-triggered services provide temporal firewall, i.e. no message will be transmitted or received at wrong time, and thus, this issue will facilitate the use of fault tolerance techniques to add more reliability to the services.
 
@@ -971,7 +971,7 @@ Consequently, both nodes introduce each other and then, can exchange the message
 
 ===== Saving an updated Image of middleware local instance =====
 In order to receive an message in the same way as processBusMessageAction() class is doing, an identical class, named as TTEMessageAction(), has been created. This class could really receive identical message with the same input arguments, but the question how can this class access to SodaPop layer. A SodaPopPeer local instance is needed. 
-Based on the assumption that each OSGi framework will host only one SodaPop instance, one instance could be saved somewhere and reused by this class whenever a new message is received. But the SodaPopPeer instance is not static object, i.e. it may be changed dynamically depending on the whole AAL space. For example, at certain instance a communication node is added/removed also within one node one or more uAAL-aware component may join or remove from a certain bus. Because of that the local instance image should be resaved dynamically.
+Based on the assumption that each OSGi framework will host only one SodaPop instance, one instance could be saved somewhere and reused by this class whenever a new message is received. But the SodaPopPeer instance is not static object, i.e. it may be changed dynamically depending on the whole uSpace. For example, at certain instance a communication node is added/removed also within one node one or more uAAL-aware component may join or remove from a certain bus. Because of that the local instance image should be resaved dynamically.
 
 Three classes from UPnP package are used to keep on one updated image of the local instance as follow:
 *NoticePeerBusesAction()
@@ -1049,7 +1049,7 @@ There are two functions of redundancy to prevent performance failure from exceed
 |}
 
 === Features ===
-Provide replication and voting mechanisms for the uAAL application and message transmitted in the uAAL space for error detection and error masking.
+Provide replication and voting mechanisms for the uAAL application and message transmitted in the uuSpace for error detection and error masking.
 
 === Design Decisions ===