Skip to content

Changes

Page history
Updated Reliability (mediawiki) authored by Carsten Stocklöw's avatar Carsten Stocklöw
Hide whitespace changes
Inline Side-by-side
Reliability.mediawiki
View page @ 94d541fa
...@@ -482,7 +482,7 @@ Because of its importance in fault tolerance operation, an Error detection frame ...@@ -482,7 +482,7 @@ Because of its importance in fault tolerance operation, an Error detection frame
| |
|- |-
| Design Diagrams | Design Diagrams
| [https://raw.githubusercontent.com/wiki/universAAL/middleware/Physical_distribution_of_EDU.png Physical Distribution of EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Conceptual_model_of_EDU.png Conceptual Model of EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Data_structure_in_EDU.png Data Structure in EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Event_list_calendar.png Event List Calendar] | [https://raw.githubusercontent.com/wiki/universAAL/middleware/Physical_distribution_of_EDU.png Physical Distribution of EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Conceptual_model_of_EDU.png Conceptual Model of EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/_Data_structure_in_EDU.png Data Structure in EDU], [https://raw.githubusercontent.com/wiki/universAAL/middleware/_Event_list_calendar.png Event List Calendar]
|- |-
| Reference Documentation | Reference Documentation
| |
...@@ -569,7 +569,7 @@ Because of that and to make the code more flexible, the main core of the EDU has ...@@ -569,7 +569,7 @@ Because of that and to make the code more flexible, the main core of the EDU has
To achieve the message classification inside the EDU, a pre-knowledge about the message specifications both in time and in value domain are required. These specifications should be delivered by the application developer at the design time and before the using of EDU. An XML configuration file has been created to make it easier for the developer to give the specification of its message. To manipulate the specification of the message, a parser function has been created for parsing the information from the XML file and providing them to the main data structure of the EDU. To achieve the message classification inside the EDU, a pre-knowledge about the message specifications both in time and in value domain are required. These specifications should be delivered by the application developer at the design time and before the using of EDU. An XML configuration file has been created to make it easier for the developer to give the specification of its message. To manipulate the specification of the message, a parser function has been created for parsing the information from the XML file and providing them to the main data structure of the EDU.
The data structure inside EDU, consists mainly of a hash table that comprises the message ID as a key and a list of check processes’ structures as a value to the related key, see next figure , where each message should pass a number of check points that are associated to the related message during the design phase. Suppose a certain message which has the message ID “101“as in the next figure. Message 101 is supposed to be configured as periodic message and have an integer value that should be tested against a certain threshold by applying the limit check and the 1st derivative check processes, therefore three check processes should applied on this message. By finding out the message ID in the hash table, a pointer to the head of the check processes list will be returned as value, for our case, the pointer refer to the periodic field. The periodic related information of message 101 such as the period value and the phase value will be found in its structure instance (Periodic struct.). After that a periodic check function will be called to compare between the stored time information and the time information that is extracted from the received message, if message 101 met its time specification, then it is considered as timely otherwise untimely message indication may be given to the diagnostic unit. The data structure inside EDU, consists mainly of a hash table that comprises the message ID as a key and a list of check processes’ structures as a value to the related key, see next figure , where each message should pass a number of check points that are associated to the related message during the design phase. Suppose a certain message which has the message ID “101“as in the next figure. Message 101 is supposed to be configured as periodic message and have an integer value that should be tested against a certain threshold by applying the limit check and the 1st derivative check processes, therefore three check processes should applied on this message. By finding out the message ID in the hash table, a pointer to the head of the check processes list will be returned as value, for our case, the pointer refer to the periodic field. The periodic related information of message 101 such as the period value and the phase value will be found in its structure instance (Periodic struct.). After that a periodic check function will be called to compare between the stored time information and the time information that is extracted from the received message, if message 101 met its time specification, then it is considered as timely otherwise untimely message indication may be given to the diagnostic unit.
By terminating the periodic check function, the pointer will refer to the second check process and so on until the check processes list is finished. By terminating the periodic check function, the pointer will refer to the second check process and so on until the check processes list is finished.
[[https://raw.githubusercontent.com/wiki/universAAL/middleware/ Data_structure_in_EDU.png| 500px| center]] [[https://raw.githubusercontent.com/wiki/universAAL/middleware/_Data_structure_in_EDU.png| 500px| center]]
===== Fault detection mechanism in time domain ===== ===== Fault detection mechanism in time domain =====
To cover fault hypothesis in time domain, two types of messages may be distinguished according to its timing behavior: To cover fault hypothesis in time domain, two types of messages may be distinguished according to its timing behavior:
...@@ -590,7 +590,7 @@ Time schedule sporadic = previous arrival time + max interarriaval time ...@@ -590,7 +590,7 @@ Time schedule sporadic = previous arrival time + max interarriaval time
It could be seen that the next scheduling point of time for sporadic message depend directly on the previous receiving point of time. Therefore a static list data structure has been created inside the sporadic check function to maintain the previous time stamping of different sporadic messages from lost. In same manner if previous data are required within the current test function, a static list may be generated, each element of the list contain the message ID field and the previous data that are required. It could be seen that the next scheduling point of time for sporadic message depend directly on the previous receiving point of time. Therefore a static list data structure has been created inside the sporadic check function to maintain the previous time stamping of different sporadic messages from lost. In same manner if previous data are required within the current test function, a static list may be generated, each element of the list contain the message ID field and the previous data that are required.
The calendar re-arranges itself dynamically after each message arrival in such a way that the earliest schedule time occupies the head position of the list. The calendar re-arranges itself dynamically after each message arrival in such a way that the earliest schedule time occupies the head position of the list.
[[https://raw.githubusercontent.com/wiki/universAAL/middleware/ Event_list_calendar.png| 400px| center]] [[https://raw.githubusercontent.com/wiki/universAAL/middleware/_Event_list_calendar.png| 400px| center]]
===== Semantic fault detection mechanism ===== ===== Semantic fault detection mechanism =====
If the ensuring of the deterministic behavior for both the middleware and the communication infrastructure will help a lot in classifying faults regarding time, this will not be the case when a sensor or actuator deviates from its normal operation. It is more complicated to catch an error from the message semantic. However a wide vary of methods are already introduced to detect anomalies of a certain process. These methods may be classified as already done by Isserman in <ref>Isermann, Rolf. Fault Diagnosis System. Heidelberg : Springer, 2006.</ref>. If the ensuring of the deterministic behavior for both the middleware and the communication infrastructure will help a lot in classifying faults regarding time, this will not be the case when a sensor or actuator deviates from its normal operation. It is more complicated to catch an error from the message semantic. However a wide vary of methods are already introduced to detect anomalies of a certain process. These methods may be classified as already done by Isserman in <ref>Isermann, Rolf. Fault Diagnosis System. Heidelberg : Springer, 2006.</ref>.
...@@ -609,7 +609,7 @@ The fault types that have been covered by the EDU are classified as general faul ...@@ -609,7 +609,7 @@ The fault types that have been covered by the EDU are classified as general faul
==Artefact #3 : Testing Module of systems fault-tolerant using Fault Injection Framework == ==Artefact #3 : Testing Module of systems fault-tolerant using Fault Injection Framework ==
=== Blackbox Description === === Blackbox Description ===
The Fault Injection Framework is used on a distributed universAAL Platform to test the system’s reliability and safety. The test case [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/1.png Cluster] consists of 5 nodes that implement AAL application on UniversAAL platform. The nodes are connected by two main communication channels; i.e. Ethernet communication and Time Triggered Ethernet communication channels, and controlled by server. The Fault Injection Framework is used on a distributed universAAL Platform to test the system’s reliability and safety. The test case [https://raw.githubusercontent.com/wiki/universAAL/middleware/1.png Cluster] consists of 5 nodes that implement AAL application on UniversAAL platform. The nodes are connected by two main communication channels; i.e. Ethernet communication and Time Triggered Ethernet communication channels, and controlled by server.
The framework includes the following: The framework includes the following:
* Development of experimental framework with the following specifications: * Development of experimental framework with the following specifications:
...@@ -634,16 +634,16 @@ The framework includes the following: ...@@ -634,16 +634,16 @@ The framework includes the following:
! align="left" bgcolor="#DDDDDD" colspan="2" | Artifact: '' Testing Module of systems fault-tolerant using Fault Injection Framework '' ! align="left" bgcolor="#DDDDDD" colspan="2" | Artifact: '' Testing Module of systems fault-tolerant using Fault Injection Framework ''
|- |-
| GIT Address | GIT Address
| http://forge.universaal.org/svn/support/trunk/reliability/Fault%20Injection%20Framework | http://github.com/universAAL/support/tree/master/reliability/Fault%20Injection%20Framework
|- |-
| Javadoc | Javadoc
| |
|- |-
| Design Diagrams | Design Diagrams
| [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/8.png Sending Algorithm], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/9.png Receiving Algorithm], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/11.png Framework Launch script], [http://forge.universaal.org/mediawiki/images/thumb/9/9e/12.png/400px-12.png Server Script], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/13.png Node Side Script] | [https://raw.githubusercontent.com/wiki/universAAL/middleware/8.png Sending Algorithm], [https://raw.githubusercontent.com/wiki/universAAL/middleware/9.png Receiving Algorithm], [https://raw.githubusercontent.com/wiki/universAAL/middleware/11.png Framework Launch script], [https://raw.githubusercontent.com/wiki/universAAL/middleware/12.png/400px-12.png Server Script], [https://raw.githubusercontent.com/wiki/universAAL/middleware/13.png Node Side Script]
|- |-
| Reference Documentation | Reference Documentation
| http://forge.universaal.org/wiki/support:RD_Fault_Injection | https://github.com/universAAL/support/wiki/RD-Fault-Injection
|- |-
|} |}
...@@ -754,7 +754,7 @@ The application with special specifications that allows the use of different tes ...@@ -754,7 +754,7 @@ The application with special specifications that allows the use of different tes
According to the universAAL platform, the data transfer between nodes depends on events, the event contains information about a device; like the status of the device or changes in the device properties.etc. For this reason a virtual device should be created, this device represents the source of the event, the event now gives information about this device. For simplicity the device was chosen to be gauge, and the property that we want to send its status by the event, is the change of battery level. According to the universAAL platform, the data transfer between nodes depends on events, the event contains information about a device; like the status of the device or changes in the device properties.etc. For this reason a virtual device should be created, this device represents the source of the event, the event now gives information about this device. For simplicity the device was chosen to be gauge, and the property that we want to send its status by the event, is the change of battery level.
The device should have unique property which differentiates each device from another, this property can be used in the receiving part nodes to express interest to specific events type that are sent on the bus; If this event is within the receiver interest, the node will receive this event. The device should have unique property which differentiates each device from another, this property can be used in the receiving part nodes to express interest to specific events type that are sent on the bus; If this event is within the receiver interest, the node will receive this event.
Multiple devices must be used, to create more than one type of events, these events are: Multiple devices must be used, to create more than one type of events, these events are:
* Startup event: to notify the receiving nodes that the process of sending events is starting up or a new loop of sending events is starting up. * Startup event: to notify the receiving nodes that the process of sending events is starting up or a new loop of sending events is starting up.
* Actual event: it is the event that will be counted and considered for the fault Injection application. This event will be sent according to the time and rate specification. * Actual event: it is the event that will be counted and considered for the fault Injection application. This event will be sent according to the time and rate specification.
...@@ -830,7 +830,7 @@ Through this section the construct steps for the fault injection application wil ...@@ -830,7 +830,7 @@ Through this section the construct steps for the fault injection application wil
'''Programs and scripts description''' '''Programs and scripts description'''
* Send Program : * Send Program :
This program is used to send the events from specific node to the other nodes, the program is design in such a way that allows the user to implement different scenarios of fault injection by changing the program parameters, find the send program framework description in following [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/8.png diagram]. This program is used to send the events from specific node to the other nodes, the program is design in such a way that allows the user to implement different scenarios of fault injection by changing the program parameters, find the send program framework description in following [https://raw.githubusercontent.com/wiki/universAAL/middleware/8.png diagram].
The Sending program phases are: The Sending program phases are:
...@@ -851,7 +851,7 @@ The Sending program phases are: ...@@ -851,7 +851,7 @@ The Sending program phases are:
# Send End event: when the whole operation of sending the events finished and the experiment is finished, the node will send the end process event to the other nodes to inform them that the experiment is finished. # Send End event: when the whole operation of sending the events finished and the experiment is finished, the node will send the end process event to the other nodes to inform them that the experiment is finished.
* Receiving Program * Receiving Program
The [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/9.png Receive Program] is used by the nodes in order to receive the events that are sent by the other nodes. It consists of two parts; the main part which initiates all the objects that are needed for the receiving task, and the csubscriber which is the actual part that is responsible for receiving the events. The [https://raw.githubusercontent.com/wiki/universAAL/middleware/9.png Receive Program] is used by the nodes in order to receive the events that are sent by the other nodes. It consists of two parts; the main part which initiates all the objects that are needed for the receiving task, and the csubscriber which is the actual part that is responsible for receiving the events.
The receiving program description is as follow: The receiving program description is as follow:
...@@ -860,7 +860,7 @@ The receiving program description is as follow: ...@@ -860,7 +860,7 @@ The receiving program description is as follow:
# Initiation process: at this stage the program initiates the required objects for the receiving process, this include the context event pattern, which will specify the restriction on receiving the events type defined by the context subscriber. # Initiation process: at this stage the program initiates the required objects for the receiving process, this include the context event pattern, which will specify the restriction on receiving the events type defined by the context subscriber.
# Create Csubscriber: this step will create context subscriber object, which is responsible for receiving the events. # Create Csubscriber: this step will create context subscriber object, which is responsible for receiving the events.
The context subscriber object, uses another thread to receive the events, it has several functions each one is responsible for a special task, the most critical part of our implementation is the [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/10.png “handle context event”] function, which is modified in order to work accordingly to Framework requirements. The context subscriber object, uses another thread to receive the events, it has several functions each one is responsible for a special task, the most critical part of our implementation is the [https://raw.githubusercontent.com/wiki/universAAL/middleware/10.png “handle context event”] function, which is modified in order to work accordingly to Framework requirements.
# Receiving events: this function is executed whenever an event is sent to the bus and it’s within the Csubscriber interest, the first step is to receive this event and identify its properties. # Receiving events: this function is executed whenever an event is sent to the bus and it’s within the Csubscriber interest, the first step is to receive this event and identify its properties.
# Assign the event source: through this phase the event source will be defined form which node is this event coming from in order to put this event within its prober counter category. # Assign the event source: through this phase the event source will be defined form which node is this event coming from in order to put this event within its prober counter category.
...@@ -876,7 +876,7 @@ The context subscriber object, uses another thread to receive the events, it has ...@@ -876,7 +876,7 @@ The context subscriber object, uses another thread to receive the events, it has
# Wait (finished): if all the nodes that sending the events finished their task, the function will wait for predefined time period in order to clean the bus from events. # Wait (finished): if all the nodes that sending the events finished their task, the function will wait for predefined time period in order to clean the bus from events.
# Exit all: at this phase the function will end all the processes that are running within the whole program and shutdown the framework. # Exit all: at this phase the function will end all the processes that are running within the whole program and shutdown the framework.
* [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/11.png Framework Launch script] * [https://raw.githubusercontent.com/wiki/universAAL/middleware/11.png Framework Launch script]
In order to run the OSGI framework and the Felix framework without the need of running Eclipse SDK, a modified pax runner which can be executed through a terminal command were can be used. Executable script will call a Felix file to launch the pax runner, this will start the frameworks required for the universAAL platform, start all the bundles and applications related to the platform, and will a start the Fault Injection Framework In order to run the OSGI framework and the Felix framework without the need of running Eclipse SDK, a modified pax runner which can be executed through a terminal command were can be used. Executable script will call a Felix file to launch the pax runner, this will start the frameworks required for the universAAL platform, start all the bundles and applications related to the platform, and will a start the Fault Injection Framework
# Initiate OSGI frame work: the script starts by defining the starting level of the osgi at which all the required bundles will be activated and ready. Also the execution environment will be defined including all the required applications. # Initiate OSGI frame work: the script starts by defining the starting level of the osgi at which all the required bundles will be activated and ready. Also the execution environment will be defined including all the required applications.
...@@ -888,14 +888,14 @@ In order to run the OSGI framework and the Felix framework without the need of r ...@@ -888,14 +888,14 @@ In order to run the OSGI framework and the Felix framework without the need of r
# Activate the application: the Fault Injection Framework will be installed and activated. # Activate the application: the Fault Injection Framework will be installed and activated.
# Start the framework: at this level all the requirements for the Felix framework are activated and ready, it will start. # Start the framework: at this level all the requirements for the Felix framework are activated and ready, it will start.
* [http://forge.universaal.org/mediawiki/images/thumb/9/9e/12.png/400px-12.png Server Script]: * [https://raw.githubusercontent.com/wiki/universAAL/middleware/12.png/400px-12.png Server Script]:
The server will control the Fault Injection Framework; it will start the script and will trigger application tasks synchronously on the nodes, by the end of this script it will collect the results. The server will control the Fault Injection Framework; it will start the script and will trigger application tasks synchronously on the nodes, by the end of this script it will collect the results.
# Send the Task: the server’s script starts by sending the assigned task to the nodes. # Send the Task: the server’s script starts by sending the assigned task to the nodes.
# Run the task in the node: the server side script will start the node’s script inside the nodes themselves. # Run the task in the node: the server side script will start the node’s script inside the nodes themselves.
# Collect the Results: after finishing the task the server will collect the results that are sent form the nodes and organize them in one results folder. # Collect the Results: after finishing the task the server will collect the results that are sent form the nodes and organize them in one results folder.
* [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/13.png Node Side Script] * [https://raw.githubusercontent.com/wiki/universAAL/middleware/13.png Node Side Script]
At the nodes side, a script is required in order to execute some essential functions to start the framework. At the nodes side, a script is required in order to execute some essential functions to start the framework.
# Update the Task: the script starts with updating the task, which is sent from the server, from the node’s specific folder. # Update the Task: the script starts with updating the task, which is sent from the server, from the node’s specific folder.
...@@ -906,7 +906,6 @@ At the nodes side, a script is required in order to execute some essential funct ...@@ -906,7 +906,6 @@ At the nodes side, a script is required in order to execute some essential funct
==Artefact #4 : Time Triggered Ethernet Extension Module == ==Artefact #4 : Time Triggered Ethernet Extension Module ==
=== Blackbox Description === === 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 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.
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. 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.
...@@ -916,13 +915,13 @@ According to the mentioned facts above , dealing with AAL environments mean deal ...@@ -916,13 +915,13 @@ According to the mentioned facts above , dealing with AAL environments mean deal
! align="left" bgcolor="#DDDDDD" colspan="2" | Artifact: '' Time Triggered Ethernet Extension Module '' ! align="left" bgcolor="#DDDDDD" colspan="2" | Artifact: '' Time Triggered Ethernet Extension Module ''
|- |-
| GIT Address | GIT Address
| http://forge.universaal.org/svn/support/trunk/reliability/TTE%20Extension | http://github.com/universAAL/support/tree/master/reliability/TTE%20Extension
|- |-
| Javadoc | Javadoc
| |
|- |-
| Design Diagrams | Design Diagrams
| [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt7.png TTEMessageAction()], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt8.png processBusMessage()], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt9.png TT-Messages transmutation native method], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt10.png TTEListener package], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt11.png nativeTTEMsgListening], [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt13.png nativeTTEMsgFetching] | [wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt7.png TTEMessageAction()], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt8.png processBusMessage()], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt9.png TT-Messages transmutation native method], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt10.png TTEListener package], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt11.png nativeTTEMsgListening], [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt13.png nativeTTEMsgFetching]
|- |-
| Reference Documentation | Reference Documentation
| |
...@@ -1062,27 +1061,27 @@ Three classes from UPnP package are used to keep on one updated image of the loc ...@@ -1062,27 +1061,27 @@ Three classes from UPnP package are used to keep on one updated image of the loc
*NoticePeerBusesAction() *NoticePeerBusesAction()
*JoinBusAction() *JoinBusAction()
*leaveBusAction() *leaveBusAction()
A new instance of [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt7.png TTEMessageAction()] with a middleware local instance as an input argument, has been created whenever one of the above classes is invoked by UPnP connector. The class diagram below describes this operation. A new instance of [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt7.png TTEMessageAction()] with a middleware local instance as an input argument, has been created whenever one of the above classes is invoked by UPnP connector. The class diagram below describes this operation.
===== TTE Transmitting Algorithm ===== ===== TTE Transmitting Algorithm =====
When a specific middleware instance has a message in one of its buses, and want to send this message to the identical bus of a remote instance, than it calls [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt8.png processBusMessage()] function from sodaPopProxy class of the related remote instance. Exactly at processBusMessage() method will be crossroads, i.e. the message tried to be transmitted through TTEthernet network interface by calling TTEMsgHandling.main(String [] sentMsg), if the sending process is done successfully, the calling of method above return 1, otherwise it returns 0. Then, the returned value is tested, if the returned value is 1 then the message will not be transmitted another time by UPnPConnector, otherwise the sending through TTEthernet service is failed and the message should be transmitted by UPnPConnector. When a specific middleware instance has a message in one of its buses, and want to send this message to the identical bus of a remote instance, than it calls [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt8.png processBusMessage()] function from sodaPopProxy class of the related remote instance. Exactly at processBusMessage() method will be crossroads, i.e. the message tried to be transmitted through TTEthernet network interface by calling TTEMsgHandling.main(String [] sentMsg), if the sending process is done successfully, the calling of method above return 1, otherwise it returns 0. Then, the returned value is tested, if the returned value is 1 then the message will not be transmitted another time by UPnPConnector, otherwise the sending through TTEthernet service is failed and the message should be transmitted by UPnPConnector.
In addition to the original input arguments (busName, msg), two other arguments will be added by main (String [] sentMsg) function, first of all the address (VLID) of the destination node, and the mode of the message. All of the input arguments have been concatenated together in one string to be as shown below: In addition to the original input arguments (busName, msg), two other arguments will be added by main (String [] sentMsg) function, first of all the address (VLID) of the destination node, and the mode of the message. All of the input arguments have been concatenated together in one string to be as shown below:
msgMod|TTEId|busName|msg msgMod|TTEId|busName|msg
Since the message modes “nul” and “one” have been reserved for exchange messages within Coupled ID-protocol, the mode of this type of messages is “two”. Since the message modes “nul” and “one” have been reserved for exchange messages within Coupled ID-protocol, the mode of this type of messages is “two”.
Since the source code of universAAL platform has been done in Java and TTE protocol is done in C language, Java Native Interface (JNI) has been used in order to exchanging data between the native method which is written in C and the Java code. Because of that, the processed message will be delivered though JNI to a native method which is responsible of broadcasting the message on the TTE network. The first diagram in the next figure describes all the processes that happen to the message within main () function until the message is delivered to the native method. Since the source code of universAAL platform has been done in Java and TTE protocol is done in C language, Java Native Interface (JNI) has been used in order to exchanging data between the native method which is written in C and the Java code. Because of that, the processed message will be delivered though JNI to a native method which is responsible of broadcasting the message on the TTE network. The first diagram in the next figure describes all the processes that happen to the message within main () function until the message is delivered to the native method.
The native method algorithm, as shown in next figure (second diagram), will receive the input argument of type jstring from Java class. This type cannot be recognised by C, in other word it should be converted to a recognisable form. Ethernet header will be added to the converted message to distinguish it as TT message not as BE message. In total the message size is 1514 bytes, which is the maximum message size can be transmitted on TTE protocol layer , it is also identical to the message size as set in the configuration. When the message size from java class is more than 1500 byte, then the message is transmitted in two bunches or more. After preparing the message, a ROW-SOCKET will be opened to send finally the message on TTE network. The implemented [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt9.png TT-Messages transmutation native method] is a java method responsible for transmitting TT-messages to the native JNI class. The native method algorithm, as shown in next figure (second diagram), will receive the input argument of type jstring from Java class. This type cannot be recognised by C, in other word it should be converted to a recognisable form. Ethernet header will be added to the converted message to distinguish it as TT message not as BE message. In total the message size is 1514 bytes, which is the maximum message size can be transmitted on TTE protocol layer , it is also identical to the message size as set in the configuration. When the message size from java class is more than 1500 byte, then the message is transmitted in two bunches or more. After preparing the message, a ROW-SOCKET will be opened to send finally the message on TTE network. The implemented [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt9.png TT-Messages transmutation native method] is a java method responsible for transmitting TT-messages to the native JNI class.
===== TTEListener package ===== ===== TTEListener package =====
A separate maven-Java project named TTEListener has been created to include all the classes assigned to achieve the listening job on TTEthernet channels. This project has been built as universAAL application within eclipse. Creating of a universAAL application means a new OSGi bundle has been created, thus an Activator class has been generated automatically. In addition to Activator class, the package includes TTMsgListening and TTEMsgFetching java classes. A separate maven-Java project named TTEListener has been created to include all the classes assigned to achieve the listening job on TTEthernet channels. This project has been built as universAAL application within eclipse. Creating of a universAAL application means a new OSGi bundle has been created, thus an Activator class has been generated automatically. In addition to Activator class, the package includes TTMsgListening and TTEMsgFetching java classes.
Two native methods have been invoked under these classes, the first one which is invoked from TTEMsgListening has been used to initiate the listening process from TTEthernet channels and save the received message in a FIFO queue, the second native method is invoked by TTEMsgFetching and is responsible for fetching the already saved messages from the queue. After dragging one message, the message is returned to TTEMsgFetching class to complete the processing on it. The flow diagram, describe how each one of these classes are interacting in this [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt10.png TTEListener package]. Two native methods have been invoked under these classes, the first one which is invoked from TTEMsgListening has been used to initiate the listening process from TTEthernet channels and save the received message in a FIFO queue, the second native method is invoked by TTEMsgFetching and is responsible for fetching the already saved messages from the queue. After dragging one message, the message is returned to TTEMsgFetching class to complete the processing on it. The flow diagram, describe how each one of these classes are interacting in this [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt10.png TTEListener package].
The main job of Activator class in such design is to trigger the listening processes in both TTEMsgListening and TTEMsgFetching, and not to wait the return value of each process. By initiating TTEMsgListening class, an individual thread is created to invoke nativeTTEMsgListening which in turns will open sockets for each TT-channel and listen for that channel. Additionally, TTEMsgListening create a new instance of TTEMsgFetching which will also create a separate thread to do the fetching job, in fact this thread enter an infinite loop, in each loop invoke its native class (nativeTTEMsgFetching()) and wait for fetching a new message, after getting a message from the native class,the message is submitted to another class for further processing while the loop invoke the native class in next iteration. The main job of Activator class in such design is to trigger the listening processes in both TTEMsgListening and TTEMsgFetching, and not to wait the return value of each process. By initiating TTEMsgListening class, an individual thread is created to invoke nativeTTEMsgListening which in turns will open sockets for each TT-channel and listen for that channel. Additionally, TTEMsgListening create a new instance of TTEMsgFetching which will also create a separate thread to do the fetching job, in fact this thread enter an infinite loop, in each loop invoke its native class (nativeTTEMsgFetching()) and wait for fetching a new message, after getting a message from the native class,the message is submitted to another class for further processing while the loop invoke the native class in next iteration.
Both of native classes (nativeTTEMsgFetching and TTEMsgListening) have involved in one dynamic library named libJniListener.so. Both of native classes (nativeTTEMsgFetching and TTEMsgListening) have involved in one dynamic library named libJniListener.so.
''nativeTTEMsgListening'' ''nativeTTEMsgListening''
This native method has been invoked by TTMsgListening class, neither input nor output argument are needed to call this native method since the main object of invoking this class is just to create a RAW-Socket for each TT-channel and listen to that socket. For our cluster model use case, each node should open four listening channels, one channel for each remote node. Thus, [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt11.png nativeTTEMsgListening] triggers four threads and return nothing. The same tasks have been achieved in all of these threads. The flow chart seen in the next figure shows the main tasks for listening thread. This native method has been invoked by TTMsgListening class, neither input nor output argument are needed to call this native method since the main object of invoking this class is just to create a RAW-Socket for each TT-channel and listen to that socket. For our cluster model use case, each node should open four listening channels, one channel for each remote node. Thus, [https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt11.png nativeTTEMsgListening] triggers four threads and return nothing. The same tasks have been achieved in all of these threads. The flow chart seen in the next figure shows the main tasks for listening thread.
The listening process begins with opening a RAW-Socket to listen on it. The same data structure have been used at the sending side will be used also at the listening side. When the message is received, several filtration processes are done on it, the first process is to check the size of the received message, when its size doesn’t equal the size of the sent message, then an error message is printed out and the algorithm flow go back to receive another message. If the message size is identical, then the message is represented as correct message. Here, another check process comes to check the completion of the message. A certain sign “||” has been put at the end of each transmitted message, if this sign hadn’t be seen at the end of the received message, then this part of the correct message will be concatenated in a string pointer, otherwise the message is completed. The listening process begins with opening a RAW-Socket to listen on it. The same data structure have been used at the sending side will be used also at the listening side. When the message is received, several filtration processes are done on it, the first process is to check the size of the received message, when its size doesn’t equal the size of the sent message, then an error message is printed out and the algorithm flow go back to receive another message. If the message size is identical, then the message is represented as correct message. Here, another check process comes to check the completion of the message. A certain sign “||” has been put at the end of each transmitted message, if this sign hadn’t be seen at the end of the received message, then this part of the correct message will be concatenated in a string pointer, otherwise the message is completed.
When the received message complete, the message mode should be detected. As mentioned before, three mode have been used to send messages on TT-channel, mode “nul” and “one” has been used for messages that carries IDs information while mode “two” has been used for exchanging messages upon buses. The first two types of messages have been transmitted without dedicating a destination address within it, so there is no need to check to which node this message has been transmitted. Since all nodes will receive the TT-message transmitted from one node (as set in cluster model configuration), the message with mode “two” should be classified according to the destination address that it carries, if the destination address match the address of TT listening channel, than the message will continue in processing otherwise the message will be ignored. When the received message complete, the message mode should be detected. As mentioned before, three mode have been used to send messages on TT-channel, mode “nul” and “one” has been used for messages that carries IDs information while mode “two” has been used for exchanging messages upon buses. The first two types of messages have been transmitted without dedicating a destination address within it, so there is no need to check to which node this message has been transmitted. Since all nodes will receive the TT-message transmitted from one node (as set in cluster model configuration), the message with mode “two” should be classified according to the destination address that it carries, if the destination address match the address of TT listening channel, than the message will continue in processing otherwise the message will be ignored.
...@@ -1090,7 +1089,7 @@ The message finally will take its final form and saving in a round FIFO queue as ...@@ -1090,7 +1089,7 @@ The message finally will take its final form and saving in a round FIFO queue as
''nativeTTEMsgFetching'' ''nativeTTEMsgFetching''
This native method has been invoked in an individual thread from TTEMsgListener java class. The main target of this method is to fetch the already received messages through TT-channels. The fetching algorithm ([http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt13.png nativeTTEMsgFetching]) has been clarified in this flow diagram. This native method has been invoked in an individual thread from TTEMsgListener java class. The main target of this method is to fetch the already received messages through TT-channels. The fetching algorithm ([https://raw.githubusercontent.com/wiki/universAAL/middleware/Tt13.png nativeTTEMsgFetching]) has been clarified in this flow diagram.
The process begins with an infinite loop, at the top of this loop, the queue status is checked whether the queue is leer or not. In case of leer queue, a new pull method is invoked, waits for a certain time and repeats the loop. The algorithm exists out of the loop when a success pull process occurs. The process begins with an infinite loop, at the top of this loop, the queue status is checked whether the queue is leer or not. In case of leer queue, a new pull method is invoked, waits for a certain time and repeats the loop. The algorithm exists out of the loop when a success pull process occurs.
In order to have a holistic view for the whole project, a class diagram for all classes developed during this thesis and their relationship to other classes in UPnP connector package, has been created. The class diagram shows the relationship among these classes in rational sequence to describe the main three functions of this development work: In order to have a holistic view for the whole project, a class diagram for all classes developed during this thesis and their relationship to other classes in UPnP connector package, has been created. The class diagram shows the relationship among these classes in rational sequence to describe the main three functions of this development work:
...@@ -1126,7 +1125,7 @@ There are two functions of redundancy to prevent performance failure from exceed ...@@ -1126,7 +1125,7 @@ There are two functions of redundancy to prevent performance failure from exceed
| |
|- |-
| Design Diagrams | Design Diagrams
| [http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/EventDuplication.png HW Redundancy(TMR)],[http://forge.universaal.org/wiki/https://raw.githubusercontent.com/wiki/universAAL/middleware/Redundancy.png Event Duplication] | [https://raw.githubusercontent.com/wiki/universAAL/middleware/EventDuplication.png HW Redundancy(TMR)],[https://raw.githubusercontent.com/wiki/universAAL/middleware/Redundancy.png Event Duplication]
|- |-
| Reference Documentation | Reference Documentation
| |
... ...
......