• Leading nodes (LN):These nodes are SNs with a specialleadingproperty derived from the clustering scheme of the network.
• Gateway nodes (GN):These nodes are SNs that act as information sinks and connec-tion to end users outside the network.
While SNs, LNs, and GNs fulfill different tasks, their hardware and software is identical.
This is a crucial prerequisite to support self-organization. For example, a destroyedleading node may result in a clustered network where some part of the network is not reachable. To recover this area, another SN has to be chosen to be the leader for this cluster.
The software of SOSEWIN nodes is described using SDL-RT models. SDL-RT is an ob-ject oriented, graphical language based on SDL. It extends SDL with real time concepts and allows usage of modern C types. In version 2.0 of the standard, the support of UML dia-grams has been added to support organization of classes and representation of the physical architecture, and how different nodes communicate with each other (Specification and de-scription language - real time (SDL), 2013). In Fig. 6.2, the basic building blocks of the SDL-RT specification and the exchanged messages of the alarm protocol are shown. Each block’s behavior is further detailed in other SDL-RT diagrams as exemplary shown in Fig. 6.3. Us-ing these models, several transformations are available to transform the models to C++ code.
The target of this code can be either a network simulator, or the real devices. To support the development of these systems, several tools and frameworks exist. The most important ones are
• a model repository for centralized management of models,
• an experiment management system that supports execution of experiments and stor-age of their results,
• and GIS-based technologies to visualize or administrate the network.
For the sake of brevity, we will not go into further details of SOSEWIN’s architecture and refer to published results (Fischer et al., 2009, 2012; Ahrens et al., 2009).
6.2. Creating The Test Model
The alarm protocol is an application created on basis of the SOSEWIN platform. For our case study, we first had to answer if this application really can be seen as a DCS, although it does not use a dynamic component platform in its technical implementation. It turned out that the principles of DCSs were present in the architectural level, but also in the SDL-RT
Figure 6.2.:SDL-RT specification of the alarm protocol. Image by (Fischer et al., 2012).
Figure 6.3.:SDL-RT State Machine of a Sensing Entity. Image by (Fischer et al., 2012).
6.2. Creating The Test Model 131
models. Fig. 6.4 shows our view on the SOSEWIN as if it’s software were developed using
leader
Figure 6.4.:SOSEWIN with a destroyed LN, and representation of this failure as a deactiva-tion of a DCS component instance.
a DCS. Each node in the system would contain a dynamic component platform, where com-ponent instances provide their functionality to other comcom-ponent instances. Some compo-nent instances would withdraw their provided functionality based on the state of the node or network conditions. For example, the component instanceLeadingEntitywould repre-sent an active connection to theleaderof a network cluster. When the network connection is be available and stable, the component instance would provide its functionality to com-municate with the leading entity. However, communicating with the component instance actually would result in a real network communication over the wire. If for some reason the communication to the leading node breaks (Fig. 6.4), this lack of communication would be represented as a withdrawal of the functionality of theLeadingEntitycomponent instance.
Any component usingLeadingEntity’s functionality has to be prepared for the dynamic availability of this functionality. In SOSEWIN, theSensingEntityis one of the central com-ponents. It senses seismic waves, performs algorithms on the continuous signal stream, and alarms its leader if an earthquake is guessed. For this case study, we therefore selected theSensingEntityas thecomponent under test. Based on the SDL-RT model of the sensing entity, we created a UML based test model. The structural and behavioral aspects of the test model are shown in Fig. 6.5, 6.6, and 6.7. In order to keep the test model small and focused, we decided to abstract some of the details of the original SDL-RT model out. First, we only modeled the behavior of theSensingEntityin detail, since we were interested in
Another abstraction was to only include the needed signals for the communication of the LeadingEntityand theSensingEntity, but skip any other signals for the communication with other SDL-RT blocks. Finally, we skipped the rich support of SDL-RT to trigger timers.
Instead, we assumed that some component representing the environment will trigger the timer events when necessary (Fig. 6.7).
In the version of the SDL-RT specification of the alarm protocol used in this case study, the SensingEntitywas only partly prepared for dynamic availability of the LeadingEntity.
While the presence of a new leader was considered using an event calledLN_SN_PrimaryLN, no event existed that notified theSensingEntityabout theabsenceof the leader. We therefore designed a new event calledPrimaryLN_Lostfor this situation. Although the system did not support this behavior yet, the MBT approach allowed us to anticipate the needed changes of the SUT, because the test model and the SUT are not tied to each other. We modeled the expected behavior of the sensing entity in a UML Statechart in Fig. 6.6. We followed our approach to explicitly model the lifecycle states and transitions. We further modeled the presence/absence of the leader functionality using an orthogonal region, so that dynamic availability is supported at any time, independent from the core functionality in the upper region of the Statechart. To be able to generate test cases for this model, we had to cre-ate additional Stcre-atecharts to emit events which drive the component under test (Fig. 6.7).
These Statecharts are designed to emit events non-deterministically, so that any of these events can be triggered at any time. However for theDCSPlatformcomponent, we followed our modeling approach and added details about the lifecycle of the DCS component, and triggering of the presence/absence events of the leading entity.