Software Architecture Project 2

7/30/2019 Software Architecture Project 2

1/77

Software Architecture: Phase 2

Dommicent Leendert - s0205006

Van Loock Jorn - s0205008

Prof.: W. JoosenAssistent: Riccardo Scandariato

1


2/77

Contents

1 Introduction 5

2 Attribute Driven Design 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Iteration 1: Decomposing the AlarmComponent . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Iteration 2: Decomposing the AlarmComponents IncomingScheduler . . . . . . . . . . . . 7

2.4 Iteration 3: Decomposing the AlarmComponents AlarmHandler . . . . . . . . . . . . . . 8

2.5 Iteration 4: Redesign of I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Iteration 5: Decomposing the I/Os IncomingModule . . . . . . . . . . . . . . . . . . . . . 12

2.7 Iteration 6: Decomposing the I/Os OutgoingModule . . . . . . . . . . . . . . . . . . . . . 13

2.8 Recapitulation: Use case overview 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 Iteration 7: Decomposing the Measurement component . . . . . . . . . . . . . . . . . . . . 16

2.10 Iteration 8: Decomposing the Measurements TrameHandler . . . . . . . . . . . . . . . . . 17

2.11 Iteration 9: Decomposing the Measurements HeartBeatDetector . . . . . . . . . . . . . . 18

2.12 Iteration 10: Decomposing the Measurements AnomalyDetection . . . . . . . . . . . . . . 20


2.14 Iteration 11: Decomposing the Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.15 Iteration 12: Decomposing the Storages MeasurementStorage . . . . . . . . . . . . . . . . 24

2.16 Iteration 13: Decomposing the Storages ConsumerStorage . . . . . . . . . . . . . . . . . . 25

2.17 Iteration 14: Decomposing the Storages AlarmStorage . . . . . . . . . . . . . . . . . . . . 26


2.19 Iteration 15: Decomposing the ControlPanel . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.20 Iteration 16: Decomposing the ControlPanels AuthService . . . . . . . . . . . . . . . . . 30

2.21 Iteration 17: Decomposing the ControlPanels AuthServices TokenGenerator . . . . . . . 31

2.22 Iteration 18: Decomposing the ControlPanels FrontController . . . . . . . . . . . . . . . . 33

2.23 Iteration 19: Decomposing the ControlPanels Backend . . . . . . . . . . . . . . . . . . . . 34


2.25 Iteration 20: Decomposing the ControlComponent . . . . . . . . . . . . . . . . . . . . . . 37

2.26 Iteration 21: Decomposing the BillingComponent . . . . . . . . . . . . . . . . . . . . . . . 38

2.27 Iteration 22: Decomposing the BillingComponents InvoiceSender . . . . . . . . . . . . . . 40

3 Final Architecture 42

2


3/77

3.1 The context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 The Overall system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Decomposition diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 Scenarios 55

4.1 User profile creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2 User profile associations with a remote monitoring module . . . . . . . . . . . . . . . . . . 55

4.3 Remote monitoring: Installation and initialization . . . . . . . . . . . . . . . . . . . . . . 55

4.4 Remote monitoring: transmission frequency reconfiguration . . . . . . . . . . . . . . . . . 56

4.5 Remote monitoring: troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.6 Remote monitoring: Alarm notification recipient configuration . . . . . . . . . . . . . . . 57

4.7 Remote control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.8 Normal measurement data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.9 Individual data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.10 Utility production planning analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.11 Information exchange towards the UIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.12 Alarm data transmission: remote monitoring module . . . . . . . . . . . . . . . . . . . . . 59

4.13 Alarm data transmission: ReMeS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.14 Remote control module de-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.15 New bill creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.16 Bill payment is received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Appendix 64

5.1 Element Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.1 Alarm Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.2 BillingComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.3 ControlComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.4 ControlPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.5 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.6 MeasurementComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.1.7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2.1 AlarmComponent - iteration 1,2,3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3


4/77

5.2.2 BillingComponent - iteration 21,22 . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.3 ControlComponent - iteration 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.4 ControlPanel - iteration 15,16,17,18,19 . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2.5 I/O - iteration 4,5,6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.6 MeasurementComponent - iteration 7,8,9,10 . . . . . . . . . . . . . . . . . . . . . . 76

5.2.7 Storage - iteration 11,12,13,14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4


5/77

1 Introduction

This report handles the second phase of the ReMeS-system. The AttributeDrivenDesign will be handledin the nextion section. In the section thereafter the final total architecture is worked out. Finallythe predefined scenarios can be found. In the appendix you find the element catalog, explaining the

responsibilities for each component, and the interfaces of all the components.

2 Attribute Driven Design

2.1 Introduction

In this section the full ADD will be explained. Hereinafter every section will be an iteration to decomposea previously created component. The report is mainly structured as a depth-first order to decomposethe system unless otherwise stated.

2.2 Iteration 1: Decomposing the AlarmComponent

Components to decompose To start the ADD we chose the most important drivers. We chose thedrivers that are architectural on the ouside of the system. This way we can use the approach to analysethe system by ADD from the outside to the inside. Because this is the first iteration we decompose theReMeS system as a whole.

Architectural Drivers We chose the next drivers to create the first decomposition:

Use Case 7: Send trame to remote device

Use Case 13: Send alarm Performance 1: Timely closure of valves

Tactics to address the requirements To achieve the drivers we chose the following tactics:

Resource Arbitration: Scheduling

We did choose the previous tactic because we want to guarantee that high priority alarms like gas leakswill be handled first. This will also guarantee the timely closure of the valves. Alternative tacticts wouldbe reduce computation overhead. We did not choose this because we do not have much control over theoverhead.

Architectural Patterns The use cases deal with the alarm section of the ReMeS-system. Incomingalarms schould be scheduled on priority, handled and there has to be a possibility to send out alarms.To design this problem we used Active Object as a pattern. The figure can be found in figure 2.

Decomposition This paragraph will always explain the working of the decomposition and the job ofnew created components.

In the chosen use cases we need to have the possibility to send a trame to a remote device. Theremote device can send an alarm to the system and the system can notify the consumer and CallCenterof this alarm. Alarms have different priorities and have to be handled in different orders. This gives us

5


6/77

3 components: a SchedulerIn for scheduling incoming alarms on priority, an AlarmHandler for handling(reading, storing, ...) the alarm and finally a SchedulerOut to schedule the outgoing alarms. You cansee this first decomposition in figure 1.

Diagrams Here you find the diagrams for this iteration. In figure 1 you can find the figure of the

decomposition tree. In figure 2 you can find the component diagram of the AlarmComponent.

Figure 1: Tree iteration 1

Figure 2: Active Object

Functionality Reallocation The IncomingScheduler has to be able to read the trames and schedulethe incoming trames by their priority. For this we create new use cases. The OutgoingScheduler doesthe same for sending trames. The AlarmHandler will handle the trames. Now we can reallocate the usecases over the tree in figure 1. The designed use cases 7 and 13 are refined, the leftover use cases andnon-functional requirements are numbered with the number from the appendix in the assignment. Thisconvention will hold throughout the report.

IncomingScheduler: (iteration 2)

UC: read trame

UC: schedule on priority

AlarmHandler: (iteration 3)

UC: save alarm

UC: load consumer configuration

UC 9: notify the consumer

OutgoingScheduler:

UC: schedule outgoing trames

UC: send trame

Other functionality:

UC 1,2,3,4,5,6,8,10,11,12,14,15,16,17

6


7/77

Availability 1,2,3

Performance 2,3

Modifiability 1,2,3

Done use cases and non-functional requirements:

UC 7, 13

Performance 1

2.3 Iteration 2: Decomposing the AlarmComponents IncomingScheduler

Components to decompose From the tree in the first iteration in figure 1, we will now make a newdecomposition. The first component to decompose is the IncomingScheduler.

Architectural Drivers The architectural drivers are the drivers we defined in the first iteration forthe IncomingScheduler.

UC: read trame UC: schedule on priority

Tactics to address the requirements Tactics are not applicable here because the drivers are all usecases. From now this paragraph wont be listed if this is the case.

Architectural Patterns For this component we did not use any specific pattern. From now if this isthe case this paragraph wont be listed.

Decomposition The main component will be a Scheduler that schedules a set of incoming data. Thescheduling is based on the priority or type of the alarm. Therefore a component Type is introduced.The Scheduler has a list of alarms ordered on priority. It keeps taking an element from the incomingBuffer and orders it in his list. To deal with starvation an aging algorithm can be used. The Schedulerprovides a function for the HandlerComponent of figure 1 to get the highest priority alarm in his list.The working is displayed in figure 4.

Diagrams Here you find the diagrams for this iteration. In figure 3 you can find the figure of thedecomposition tree of the IncomingScheduler. In figure 4 you can find component diagram of the Incom-ingScheduler.


7


8/77

Figure 4: Incoming scheduler

Functionality Reallocation We will not decompose the components in the IncomingScheduler any-more. From now the previous created use cases for the IncomingScheduler are satisfied. The other usecases are not changed and remain assigned to their components like stated in iteration 1.


UC 7, 13

Performance 1

2.4 Iteration 3: Decomposing the AlarmComponents AlarmHandler

Components to decompose From the tree in the first iteration in figure 1, we will now make a newdecomposition. The IncomingScheduler was decomposed in iteration 2. The next one is the AlarmHan-dler.

Architectural Drivers The architectural drivers are the drivers we defined in the first iteration forthe AlarmHandler.

UC: save alarm

UC: load consumer configuration

UC 9: notify the consumer

Decomposition A TrameTreader is needed for reading the incoming trames from the IncomingSched-uler of iteration 2. The TrameTreader uses ConsumerInfo, which has a database connection, to get theconsumer of the valve. With that knowledge there is access to the notificationpreferences. We need thisto inform the consumer of the alarm and we can create a message for that in the ConsumerMsgBuilder.This can be send to the OutgoingScheduler of figure 1. Finaly the TrameReader will save the alarmwith a connection to the database. This way low battery alarms can be saved so they can be viewed inthe control panel. Likewise storing the alarms gives the opportunity to the consumer to set an alarm asa false positive from the control panel. The TrameTreader will also save the status of the valve (openor closed). This is necessary because the gas leaks require the valve to be shutdown. In that case theTrameReader will want to call a function in the OutgoingScheduler to send a command to shutdownthe valve. The TrameReader can determine through which technology the trame was sent for sending

8


9/77

back the shutdown command (see interfaces of I/O OutgoingModule) through the same technology. Thisworking is displayed in figure 6.

Diagrams Here you find the diagrams for this iteration. In figure 5 you can find the decompositiontree of the AlarmHandler. The component diagram of the AlarmHandler is in figure 6.


Figure 6: Alarm Handler

Functionality Reallocation We will not decompose the components of the AlarmHandler anymore.

From now the previous created use cases for the AlarmHandler are satisfied. The other use cases arenot changed and remain assigned to their components like stated in iteration 1.


UC 7, 9, 13

Performance 1

2.5 Iteration 4: Redesign of I/O

Until now two of three components of figure 1 are decomposed and should do what they have to do. This3 components are all related with the alarms. Lets call this set the AlarmComponent. On the same

9


10/77

level, next to the AlarmComponent we could define a MeasurementComponent for use case 8 (and latera ControlComponent). They would handle the measurement data (and for the ControlComponent thetest of the connection when a new valve is installed at a consumers home).

Architectural Drivers From now, the MeasurementComponent will be included at high level. Avail-

ability 2 (missing measurements) will be split over in two seperate ones. The first Availablity 2a willrepresent the acknowledgement of every received trame, will be handled in the Incoming Module. Thesecond Availablity 2b will represent the detection of dead valves, valves that arent sending any dataanymore, will be handled in the MeasurementComponent. Modifiability 1 is seperated anologue.

UC 8: Send measurement

Availablity 2a: Acknowledge every received trame

Availablity 2b: Detection of dead valves

Modifiability 1a: Sending commands to remote smart devices (HAS).

Modifiability 1b: Consumer can have a dynamic billing profile

Modifiability 3: Decentralized electricity generation

Tactics to address the requirements

Generalize the module

Anticipate expected changes

To achieve Modifiability 1 new commands has to be sent out to smart remote devices. Adding suchcommands and keeping seperation of concerns brought us to Generalize the module. We chose this tacticbecause this new functionality isnt tightly coupled with other components but we can reuse yet existingcomponents. Modifiability 3 asks us to easily add new components like the AlarmComponent & Measure-mentComponent. This extra component would handle trames sent by the remote module with data of

produced power. By placing an I/O IncomingModule these trames can easily be filtered out and passedto that extra component. Anticipate expected changes is applied here. With this design new functionscould easy be plugged in in the ReMeS-system.

We didnt chose Restrict communication path because there are many unexpected connections thathave to be made in the system, so this tactic doesnt seem feasible.

Decomposition We could set the MeasurementComponent, AlarmComponent and (later) the Con-trolComponent on one hypothetical level with connections to a Storage component. For good designrequirement like speration of concerns 1 module for the incoming messages could be build and placed infront of those 3 components. This corresponds to the tactics we want to use. Analogue a component tosend messages is placed behind those 3 components. This I/O Module will be decomposed in iteration 5

(for I/O:Incoming Module) and iteration 6 (for I/O:Outgoing Module). In this situation we assume theOutgoing Module can send and work instantly. We can drop the Outgoing Scheduler in the AlarmCom-ponent. We will get a new design tree like in figure 7. A high level overview is in figure 8. For readabilityonly 1 methodconnection is drawed between the components. There could be more and these will bespecified and get clear throughout the next iterations.

Modifiability 1a can now be easy included for its part of sending commands to Home AutomationSystems. The OutgoingModule can easy be extended for doing this. Modifiability 1b will be explainedin iteration 21.

From now we will use this tree as the new tree to work with. The decomposition of the AlarmComponentin figure 7 stays the same as created in iteration 2 and 3.

10


11/77

Diagrams Here you find the diagrams for this iteration:

Figure 7: New decomposition tree

A short overview of the components iterations:

AlarmComponent: Iteration 1 AlarmComponent - IncomingScheduler: Iteration 2

AlarmComponent - AlarmHandler: Iteration 3

I/O - IncomingModule: Iteration 5

I/O - OutgoingModule: Iteration 6

MeasurementComponent: Iteration 7

Figure 8: The new high-level overview

Functionality Reallocation Here you find the new reallocation of the uses cases over the new com-ponents. If the Incoming and Outgoing Module are decomposed (after itaration 6) a total recapitulationof the done use cases will be provided.

IncomingModule: (iteration 5)

Availablity 2a: Acknowledge every received trame

UC: route messages

Modifiability 3: Decentralized electricity

OutgoingModule: (iteration 6)

UC: create messages

UC: send messages


11


12/77

MeasurementComponent: (iteration 7)

Availablity 2b: Detection of dead valves

UC: Store measurement

UC: notify consumer/call center

Performance 2: Anomaly detection

2.6 Iteration 5: Decomposing the I/Os IncomingModule

Components to decompose This iteration and the next one will be the decomposition of the I/Ocomponent. This component represents the handling of incoming data and the possibility to send outdata. This iteration will do the decomposition of the Incoming Module of figure 7.

Architectural Drivers Like stated in iteration 4, we can now handle the created use case: Availablity2a: acknowledge received data. Due to the design change in iteration 4, the Incoming Module needs theability to route messages to the right component (MeasurementComponent or AlarmComponent of figure8). Alarms must go to the AlarmComponent and measurements must go to the MeasurementComponent.

Availablity 2a: acknowledge received data

UC: route messages

Modifiability 3: Decentralized electricity


Ping/Echo


We chose Ping/Echo tactic because the messages themself represent the ping and our acknowledgmentcan be the echo. This doesnt give us so much overhead as the heartbeattactic, then we would have tomonitor every module continiously. The tactic Anticipate expected changes gives us the opportunity toadd new components to the ReMeS system in the future.

Architectural Patterns To route the messages the each component we could just use a messagerouter.

Decomposition To keep the design of figure 8, the Incoming Module must have a component Mes-sageRouter that routes the incoming data to the right component (AlarmComponent, MeasurementCom-

ponent and later in iteration 20 the ControlComponent). The routing can be done on the type of theincoming data. A component Type is introduced that can determine the type of the incoming data.Finally there is a connection to the OutgoingModule of the I/O. This connection is to tell the OutgoingModule to send an acknowledge of the received data. The technology through which the trame wasreceived is send as paramter with the command. This way an acknowledge can be sent back through thesame technology. The working of this is displayed in figure 10.

Modifiability 3 states that individual trames of utility usages and produced power at the consumershome could be sent to the system and handled. A new trame type for these data can easy be in-cluded. A component to handle the trames of the own produced power can be added thanks to theMessageRouter. This component will handle this trame similar like the MeasurementComponent. TheMessageRouter can then send the received trames to the right component. This way consumers who arenot producing power wont be affected if this would be introduced.

12


13/77

Diagrams Here you find the diagrams for this iteration. In figure 9 you can find the figure of thedecomposition tree of the Incoming Module. In 10 you can find the component diagram of the IncomingModule.

Figure 9: Decomposition of the incoming module of the I/O component

Figure 10: Component diagram of the incoming module

Functionality Reallocation The use cases of the Incoming Module are fulfilled. The components inthe Incoming Module will not be decomposed any further.

2.7 Iteration 6: Decomposing the I/Os OutgoingModule

Components to decompose This iteration will be the decomposition of the outgoing module of theI/O component, see figure 7. This component represents the handling of the data to be send.

Architectural Drivers The Outgoing Module must accept requests to create and send a specific trameto a location.

UC: create messages

UC: send messages



13


14/77

Generalize the module

This tactic was chosen because it gives us the opportunity to reuse the OutgoingModule. This wayModifiability 1a can be implemented very fast.

Decomposition A component MessageCreator can create messages for every connectiontechnologyand has an interface for all data that must can be sent. E.g: sendAcknowledge(valve) from the IncomingModule, sendConsumerAlarmNotification(message) from the AlarmComponent, ... (see the interface inthe appendix) It sends this message to the actual Sender who sends the message to its destination. EachSender represents a sender for a different technology. Because we added more general methods (E.g:notifyConsumer(..) see interfaces in the appendix) to the MessageCreators interface, these methods canbe reused over and over again by different components. This decomposition is displayed in figure 12.

Diagrams Here you find the diagrams for this iteration. In figure 11 you can find the figure of thedecomposition tree of the Outgoing Module. In 12 you can find the component diagram of the OutgoingModule.

Figure 11: Decomposition of the outgoing module of the I/O component

14


15/77

Figure 12: Component diagram of the outgoing module

Functionality Reallocation The use cases of the Outgoing Module are fulfilled. The components inthe Outgoing Module will not be decomposed any further.

2.8 Recapitulation: Use case overview 1

In this section we give a short review of the completed and incompleted use cases and non-functionalrequirements.

Completed use cases:

UC 7: send trame to remote device - Outgoing Module

UC 8: send measurement - Incoming Module(routing to Measurement)

UC 9: notify consumer - AlarmComponent & Outgoing Module

UC 13: send alarm - AlarmComponent

Completed non-functional requirements: Performance 1: Timely closure of valves - AlarmComponent

Availability 2a: Acknowledge received data - Incoming/Outgoing Module

Modifiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule

Modifiability 3: Decentralized electricity generation - IncomingModule

Use cases to do:

UC 1,2,3,4,5,6,10,11,12,14,15,16,17

Non functional requirements to do:

Availability 1,3

Availability 2b: Detection of dead valves

Performance 2,3

15


16/77

Modifiability 1b,2

2.9 Iteration 7: Decomposing the Measurement component

Components to decompose This iteration will be the decomposition of the Measurement component.This is the last component of figure 7 to be decomposed. This component does the analysis of the receivingmeasurements. The subcomponents will be decomposed in iteration 8, 9 and 10.

Architectural Drivers The Measurement component receives from the Incoming Module only trameswith measurement data. It must be possible to store the data in the database, the component has todetect if there are dead valves and finally it must do an anomaly detection on the measurement data tocreate an alarm if necessary. This gives analogue on the reallocation in iteration 4 the following drivers:

UC: Detect missing heartbeat (to do in HeartBeatDetector)

UC: Store measurement (next iteration - TrameHandler)

UC: notify consumer/call center (to do in Anomaly Detection)

Performance 2: Anomaly detection (to do in Anomaly Detection)

UC 10: Detect anomaly (to do in Anomaly Detection)

Decomposition Because the component can be busy when new measurements are coming in, wellstart with placing a Buffer at the incoming port of the Measurement component. The TrameHandlerreads the trame and sees from which valve the measurement is coming. The TrameHandler has access tothe database to get the consumer of the valve. Second, the measurements are stored with the consumer id.The AnomalyDetection analyses the data by comparing it to previous measurements and false positivesfrom the database with respect to the consumersettings. If an anomaly is detected, the AnomalyDetectioncreates an alarm and sends it to the AlarmComponent like the incoming module would do. Finally theTrameHandler informs the HeartBeatDetector from which valve a measurement is received. The Detector

checks if valves are not sending any data anymore and has the possibility to send a command to theOutgoing Module. The Outgoing Module will send a command to the valve with a request to send data.

In figure 14 you can see the working more easily. The measurement trames come from the IncomingModulein the buffer.

Diagrams Here you find the diagrams for this iteration. In figure 13 you can find the figure of thedecomposition tree of the MeasurementComponent. In 14 you can find the component diagram of theMeasurementComponent.

Figure 13: Decomposition the measurement component


MeasurementComponent: this - Iteration 7

16


17/77

TrameHandler: Iteration 8

HeartBeatDetector: Iteration 9

AnomalyDetection: Iteration 10

Figure 14: Component diagram of the measurement component

Functionality Reallocation Reallocation of functions over MeasurementComponents components:

TrameHandler: (iteration 8):

UC: Read trame UC: Store measurement

HeartBeatDetector: (iteration 9):

UC: Detect missing heartbeats

Availability 2b: Detect dead valves

AnomalyDetection: (iteration 10):

UC: notify consumer

Performance 2: Anomaly Detection

UC 10: Detect anomaly

2.10 Iteration 8: Decomposing the Measurements TrameHandler

Components to decompose This iteration will be the decomposition of the TrameHandler of theMeasurement component in figure 13.

Architectural Drivers Like said in iteration 7, this component has to read trames and create aMeasurementObject to store the received measurement in the database.

UC: Read trame

UC: Store measurement

17


18/77

Decomposition The TrameReader gets an incoming measurementtrame from the Buffer. It reads thetrame and gets from which valve the trame is coming. With a connection to the database the consumerof that valve is received. With the help of MeasurementData its possible to create a MeasurementObjectfrom the data with the consumer id. This MeasurementObject can be stored in the database. There isa connection to the AnomalyDetection to analyse the measurementdata. There is also a connection tothe HeartBeatDetector for updating his table to say that a new measurement from a specific valve is

received. The working gets clear in figure 16.

Diagrams Here you find the diagrams for this iteration. In figure 15 you can find the figure of thedecomposition tree of the TrameHandler. You find the component diagram of the TrameHandler infigure 16.

Figure 15: Decomposition the TrameHandler in the Measurement component

Figure 16: Component diagram of the TrameHandler

Functionality Reallocation The use cases of the TrameHandler are fulfilled. The components in theTrameHandler will not be decomposed any further.

2.11 Iteration 9: Decomposing the Measurements HeartBeatDetector

Components to decompose This iteration will be the decomposition of the HeartBeatDetector ofthe MeasurementComponent of figure 13 in the MeasurementComponent.

Architectural Drivers This component checks if remote valves keep sending measurements. Thedrivers are analogue as those stated in iteration 7.

UC: Detect missing heartbeats

Availability 2: Detect missing measurements

18


19/77

Tactics to addresss the requirements To achieve the drivers we chose the following tactic:

HeartBeatDetection

Because the modules have to send with a regular their messages are in fact already a heartbeat. So it

is easier to implement this than any other tactic. For example with Ping/Echo we would also need aconnection to OutgoingModule to continiously ping the remote module. This would create unnecessaryoverhead.

Decomposition To achieve the requirements we need a table having entries of the valves from whowe need measurements. This table also needs timing data per valve, this represents in which time wewant to have at least 1 incoming measurement of that valve. We will call this component the TimeTable.The TimeTable provides a function to reset an entry of a specific valve with a given time. The callerof this function will be the TableManager. The consumer is also passed to it so a specified timing canbe set per valve according to the consumers module configuration. If a new measurement is receivedthis TableManager will be notified with the consumer object, the valveId, the valveAddress and thetechnology for that valve. All coming from the TrameReader. The Manager updates the table for thatvalve and sets the timing to the normal timing for the valve. The TimeTable will do a countdown onthe timings per tick. If the timing of a valve becomes zero, a request to remote valve must be send.Therefore we have a component TableAnalyser. This component checks in the TimeTable for negativevalues. If found, a command to the OutgoingModule can be created to send to the remote valve arequest for sending some data. This way the TableAnalyser can check how many misses happened andcan create an alarmTrame if this is over a specified amount (3 times). The AlarmComponent will notifythe consumer and store it in the database so it can be viewed in the ControlPanel. At last the TimeTablehas a delDevice method. When a consumer decides in the control panel to stop using the system, nonew measurements of that module have to be received. This working is like in figure 18.


decomposition tree. The working like explained above can be found in the component diagram in figure18.

Figure 17: Decomposition the HeartBeatDetector in the Measurement component

19


20/77

Figure 18: Component diagram of the HeartBeatDetector

Functionality Reallocation The use cases of the HeartBeatDetector are fulfilled. The componentsin the HeartBeatDetector will not be decomposed any further.

2.12 Iteration 10: Decomposing the Measurements AnomalyDetection

Components to decompose This iteration will be the decomposition of the AnomalyDetection. Thisis last component to be done of the MeasurementComponent like displayed in figure 13.

Architectural Drivers This component does the detection of anomalies in the measured data com-ing from the TrameHandler in the MeasurementComponent (figure 14). The drivers are those of the

reallocation in iteration 7.

UC: notify consumer

Performance 2: Anomaly Detection

UC 10: Detect anomaly

Tactics to addresss the requirements Performance 2 says we need a scheduler, scheduling on theenvironment mode, normal or overloaded, of the system. Additionally the load is balanced over multipleinstances. To achieve the drivers we chose the following tactics:

Resource Arbitration: scheduling

Resource Management: concurrency

We do not know yet the anomalyAlgorithms, so we cant reduce the computational overhead or increasethe computation efficiency.

Architectural Patterns The scheduling can be done like in the first iteration for the AlarmComponentwith the ActiveObject pattern with an extra ModeComponent. For concurrency and the balancing overmultiple instances we chose the LeaderFollower pattern.

Decomposition Because the system can operate in 2 modes, the normal environment and the over-loaded mode, we start with a component that represents the Mode of the AnomalyDetectionComponent.

20


21/77

The SchedulingComponent, scheduling depending on the mode, is connected to that. It can set the modedepending on the amount of requests. The Scheduler receives also the consumer of the measurementdata,to schedule on his SLA in overload mode. The AnomalyAlgorithm gets the next measurementdata fromthe Scheduler that needs to be processed as first. The AnomalyDetection gets the other measurementsand alarms of that consumer out of the database. It has now all the data available to run an algo-rithm to detect anomalies. The alarms and previous measurements are needed to learn from previous

false positives. The alarms will hold data representing the alarm was true or false. The consumer canset this in the ControlPanel (see later). The AnomalyAlgorithmcomponents work like the LeaderFol-lowerpattern. This way the load is balanced over multiple instances. The AnomalyAlgorithm can do agetConsumer(consumerId) (consumerId is in the measurementData) to get the valve properties of thosemeasurements. This way an alarmTrame can be send to the AlarmComponent like it was an alarmTramefrom a remote valve. The alarm will then be handled correctly. This working is like in figure 20.

Diagrams Here you find the diagrams for this iteration. In figure 19 you can find the figure of thedecomposition tree. The working like explained above can be found in the component diagram in figure20.

Figure 19: Decomposition of the AnomalyDetection in the Measurement component

Figure 20: Component diagram of the AnomalyDetection

Functionality Reallocation The use cases of the AnomalyDetection are fulfilled. The componentsin the AnomalyDetection will not be decomposed any further.

21


22/77


Uptill now all the components of figure 7 and figure 13 are decomposed. We have:

AlarmComponent: Iteration 1

AlarmComponent - IncomingScheduler: Iteration 2 AlarmComponent - AlarmHandler: Iteration 3




MeasurementComponent - TrameHandler: Iteration 8

MeasurementComponent - HeartBeatDetector: Iteration 9

MeasurementComponent - AnomalyDetection: Iteration 10

A review of the completed and incompleted use cases and non-functional requirements:

Completed use cases: UC 7: send trame to remote device - Outgoing Module



UC 10: detect anomaly - AnomalyDetection


Completed non-functional requirements:

Performance 1: Timely closure of valves - AlarmComponent

Performance 2: Anomaly Detection - AnomalyDetection


Availability 2b: Detection of dead valves - MeasurementComponent

Modifiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modifiability 3: Decentralized electricity generation - IncomingModule

Use cases to do:

UC 1,2,3,4,5,6,11,12,14,15,16,17


Availability 1,3

Performance 3

Modifiability 1b,2

2.14 Iteration 11: Decomposing the Storage

Components to decompose From section 2.13 we see a lot of components are decomposed. Themissing high priority keypart for letting all of these components work is storage. In this section we willbegin the decomposition of the StorageComponent. Adding the storage to the current system (figure 7)gives us figure 21.

Architectural Drivers Related to the StorageComponent are the following drivers:

Availability 1: Measurement database failure

Performance 3: Requests to the measurement database

22


23/77

Figure 21: Adding the Storage to the system

Decomposition Because the drivers state the database of the measurements has to be somewhat apartfrom the other databases we chose to make 3 different components. We get the MeasurementStorage,ConsumersStorage and the AlarmStorage. In front of those components we place a QueryHandler havingan interaface of available queries for the other external components. The QueryHandler completes all ofthese queries by routing them to the right storage.

Diagrams Here you find the diagrams for this iteration. In figure 22 you can find the figure of thedecomposition tree. The working like explained above can be found in the component diagram in figure

23.

Figure 22: The decomposition tree of the Storage


Storage: this - Iteration 11

MeasurementStorage: Iteration 12

ConsumerStorage: Iteration 13

AlarmStorage: Iteration 14

Figure 23: Component diagram of the Storage

Functionality Reallocation

MeasurementStorage: (iteration 12)

23


24/77



UC: Store & retrieve

ConsumerStorage: (iteration 13)


AlarmStorage: (iteration 14)


2.15 Iteration 12: Decomposing the Storages MeasurementStorage

Components to decompose In decomposing the storage we will start with the MeasurementStorageof figure 22. This is an important component with some serious drivers.

Architectural Drivers The key drivers for the MeasurementStorage are those stated in the realloca-tion of iteration 11:




Tactics to addresss the requirements Performance 3 says we need a scheduler, scheduling on theenvironment mode, normal or overloaded, of the system. Additionally the load is balanced over multipleinstances. To achieve the drivers we chose the following tactics:

Resource Arbitration: Scheduling

Resource Management: Concurrency

We cant increase the computational efficiency because the DBMS will handle the queries. We assumethis will do the queries as efficient as it can be.

Architectural Patterns We chose to use a DataMapper to access the database. The LeaderFol-lowerpattern added for DataMappers to deal with concurrency. And finally an ActiveObject is used forthe scheduling.

Decomposition We have a Scheduler, scheduling depending on the mode of the ModeComponent. The

scheduler can set this mode if he receives a specified amount of requests in a specified interval of time. Ifin overload mode the Scheduler does a query to the ConsumerStorage to get the consumer for his SLAto schedule getqueries. The Scheduler could hold a cache himself that is used if in overloaded mode.Finally the Scheduler uses a DataMapper to access the Database. The Database is built out of a masterand slaves. The Mapper can read from cheaper slaves but only write to (and read from) the fast master.The master will write to the slaves. The slaves will be a replica of the master. The DataMappers own apriority map. First the fast master, second the cheaper slave1, third slave2. Each write will try to writein this order untill a write succeeds. If the master is down a slave will perform the write and write tothe other lower priority databases. If the master does a recovery, he recovers from the available highestpriority slave. If he is running again the DataMappers can write again to the master. The working isdisplayed in figure 25.

24


25/77


Figure 24: The decomposition tree of the Storages MeasurementStorage

Figure 25: Component diagram of the Storages MeasurementStorage

Functionality Reallocation The use cases of the MeasurementStorage are fulfilled. The componentsin the MeasurementStorage will not be decomposed any further.

2.16 Iteration 13: Decomposing the Storages ConsumerStorage

Components to decompose The MeasurementStorage of figure 22 was decomposed in the previousiteration. The component for this iteration will be the ConsumerStorage.

Architectural Drivers The key drivers for the ConsumerStorage are those stated in the reallocationof iteration 11:


Architectural Patterns We chose to use a DataMapper to access the database.

Decomposition Only 2 components are used inside the ConsumerStorage. We use a DataMapper toaccess the final Database.

25


26/77


Figure 26: The decomposition tree of the Storages ConsumerStorage

Figure 27: Component diagram of the Storages ConsumerStorage

Functionality Reallocation The use cases of the ConsumerStorage are fulfilled. The components inthe ConsumerStorage will not be decomposed any further.

2.17 Iteration 14: Decomposing the Storages AlarmStorage

Components to decompose The last component of figure 22 that will be decomposed is the Alarm-Storage and will be done in this section. The working of this component is completely like the Con-sumerStorage from the previous itertion. We will only give the diagrams here.


decomposition tree. The component diagram can be found in figure 29.

26


27/77

Figure 28: The decomposition tree of the Storages AlarmStorage

Figure 29: Component diagram of the Storages AlarmStorage

Functionality Reallocation The use cases of the AlarmStorage are fulfilled. The components in theAlarmStorage will not be decomposed any further.


Uptill now all the components of figure 21 are decomposed. We have:


AlarmComponent - IncomingScheduler: Iteration 2







MeasurementComponent - AnomalyDetection: Iteration 10 Storage: Iteration 11

Storage - MeasurementStorage: Iteration 12

Storage - ConsumerStorage: Iteration 13

Storage - AlarmStorage: Iteration 14



UC 7: send trame to remote device - Outgoing Module


27


28/77


UC 10: detect anomaly - AnomalyDetection




Performance 2: Anomaly Detection - AnomalyDetection Performance 3: Requests to the measurement database - MeasurementStorage

Availability 1: Measurement database failure - MeasurementStorage



Modifiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule

Modifiability 3: Decentralized electricity generation - IncomingModule

Use cases to do:

UC 1,2,3,4,5,6,11,12,14,15,16,17


Availability 3

Modifiability 1b,2

2.19 Iteration 15: Decomposing the ControlPanel

Components to decompose The current system is the complete decomposition of figure 21. Thenext priority is the ControlPanel. Imagine we add a component ControlPanel next to Storage from figure21. This results in figure 30.

Figure 30: Adding the ControlPanel to the current system

Architectural Drivers At high-level the ControlPanel has to do a lot of the remainig use cases:

UC 1: Log in

UC 2: Log off

UC 3: Register consumer UC 4: Unregister consumer

UC 5: Associate device to consumer

UC 6: Customize consumer profile

UC 11: Operate actuator remotely

UC 12: Set alarm recipients

UC 14: Request consumption predictions

UC 17: Request consumption predictions

Architectural Patterns We will use a FrontController for the ControlPanel to receive all its requests.It will pass them to other components and respond to the client.

28


29/77

Decomposition We use a FrontController for the ControlPanel. We assume our ControlPanel will bea website. But a program with a connection through HTTP is possible. The FrontController will receiveall the incoming HTTP requests and handle them. We need an AuthenticationService for handling theauthentication of people that log in on the system. We have a GUI component representing the view.This component includes just the webpages to be displayed. We could have a page for consumers toregister, pages for the CallCenter operators, pages for the consumers, pages for the researchers (UC 17),

pages for the UtilityProviders for seeing the predictions (UC 14) and pages for EmergencyServices wherethey could see high priority alarms like gas leaks so they have direct access to urgent data. The lastcomponent will be the Backend for the business logic of the ControlPanel. This Backend will includecomponents for handling the operations available in the ControlPanel. Therefore these components willhave a direct connection to the StorageComponent for getting data.

The pages for the CallCenter operators could have a section alarms. In that section all alarms anddetails in the database could be listed. Alarms set in the database coming from the AlarmComponentlike low batteries or leaks can now be viewed by the CallCenter operators on their ControlPanel.

The incoming HTTP requests will directly be on the FrontController and not to the IncomingMod-ule of iteration 5. The addition of this components does not have any impact on the previous created

components.


Figure 31: The decomposition tree of the ControlPanel


ControlPanel: this - Iteration 15

AuthService: Iteration 16

FrontController: Iteration 18

Backend: Iteration 19

Figure 32: Component diagram of the ControlPanel

29


30/77


31/77

Figure 33: The decomposition tree of the ControlPanels AuthService

Figure 34: Component diagram of the ControlPanels AuthService

Functionality Reallocation The use cases of the AuthService are fulfilled. We will do a decomposi-tion of the TokenGenerator in the next iteration. The use cases for the TokenGenerator are:

UC: Generate consumertoken

UC: Generate representativetoken UC: Generate techniciantoken

2.21 Iteration 17: Decomposing the ControlPanels AuthServices Token-Generator

Components to decompose In this section we will decompose the TokenGenerator of the AuthSer-vice in the ControlPanel.

31


32/77

Architectural Drivers The key drivers for the TokenGenerator are those stated at the end of theprevious section:

UC: Generate consumertoken

UC: Generate representativetoken

UC: Generate techniciantoken

We generate 3 different tokens so there is a possibility to check on the incoming token from the clientwhat kind of user it is. A consumer, a representative (CallCenter operator) or a technician.

Decomposition If a request comes in to generate a token it comes in on the RequestHandler. This onecalls the ConsumerToken or the RepresentativeToken, depending the request, to generate a token. Eachtoken will be unique and hard to guess. But it is possible when a token is generated to determine fromwhich generator it is coming. To deal with low priority UC 14 and 17 we could add a tokengenerator forresearchers and UtilityProviders. Finally a generator could be added for EmergencyServices so they canaccess urgent alarms like gasleaks. This should allow them to login too and see everything where theyhave access to. This is not displayed in the figures.


Figure 35: The decomposition tree of the ControlPanels AuthServices TokenGenerator

Figure 36: Component diagram of the ControlPanels AuthServices TokenGenerator

Functionality Reallocation The use cases of the TokenGenerator are fulfilled. The components inthe TokenGenerator will not be decomposed any further.

32


33/77

2.22 Iteration 18: Decomposing the ControlPanels FrontController

Components to decompose In this section the FrontController of the ControlPanels in figure 31will be decomposed.

Architectural Drivers The key drivers for the AuthService are those stated in the reallocation ofiteration 15:

UC: Reading incoming requests

UC: Pass requests to backend

UC: Pass backend response to the GUI

UC: Send GUI to client

UC: Check permissions for an operation

UC: Check if login or session is valid

Decomposition We start with a component RequestReader that handles all the incoming HTTPrequests. The session is checked or a login is performed with the AuthService described above. Noteverybody can make the same requests to the Backend. We generated different types of tokens dependingon the users that logged in (described in iteration 17). The RequestReader could extract the token fromthe request and with the help of the ServiceLookupTable see if the operation is permitted for that type oftoken (user). Evenso the checklogin returns the userId. With that userId rules for example setRecipientcan be checked. He can only do this query if the target userId is the same as the user doing the operation.The ServiceLookupTablehas thus database access to check these high-level rules. He needs only access tothe consumerdatabase. If the request is granted it is passed to the MessageRouter. The MessageRouterroutes the operation to the right component of the Backend (next iteration). Otherwise a error is sendback to the client. The response of the Backend is send to the GUI component of figure 31. TheGUI component generates with the received dataset (e.g: MeasurementData) a ready html page. Thegenerated page is send back to the FrontController who sends it back to the client.


Figure 37: The decomposition tree of the ControlPanels FrontController

33


34/77

Figure 38: Component diagram of the ControlPanels FrontController

Functionality Reallocation The use cases of the FrontController are fulfilled. The components inthe FrontController will not be decomposed any further.

2.23 Iteration 19: Decomposing the ControlPanels Backend

Components to decompose In this section the Backend of ControlPanel in figure 31 will be decom-posed.

Architectural Drivers The drivers for this iteration are handling the functions that must be donefrom the ControlPanel and are also listed in the interfaces section. We will give them here too:

UC: registerUserByCallCenter - Registering a user from the CallCenter.

UC: registerUserByUser - Registering a user himself from the website. Afterwards the registrationhas to be approved by the CallCenter.

UC: getNonApprovedUsers - Returns the non-approved users.

UC: approveUser - Approve a user.

UC: confirmViaMail - The users confirms his registration by the http-link in the confirmation mail.

UC: removeUserByUser - Sets the users devices as non active. Sets a user property he wants to

be deleted. The delDevice from the HeartBeatDetector is invoced. UC: removeUserByCallCenter - The CallCenter removes a user.

UC: getRemovedUsers - Returns a list of users who want to stop using the system (set by re-moveUser(..)). A technician has to come by to pick up the modules

UC: deleteUser - After the technician has picked the modules he can invoke this method. The useris now completely deleted from the system.

UC: addModule - A remote module is coupled to a user.

UC: addActuator - The actuator is coupled the module, that is coupled to a user.

UC: changeAlarmRecipient - Changes the recipient of the alarms for a user owning a module.

UC: changeMeasurementsTresholds - Change the treshold of a device.

UC: changeDeviceConfig - Change the configuration of a device. Like sending timings and tresholds.The new configuration can be sent with the OutgoingModule.

34


35/77

UC: changeMailAddress - Sets the new mailaddress.

UC: changeSmsNumber - Sets the new smsnumber.

UC: changeLocation - Sets the new location.

UC: setDeviceStatus - Can set a device status. E.g: open, closed,.. A shutdowncommand can besent with the OutgoingModule.

UC: setAlarmReceiveTechn - Set for the alarms coming from a device the notificationtechnologyfor the consumer.

UC: getAlarms - Gets all the alarms. The CallCenter sees all the alarms. The consumer only hisalarms.

UC: markAlarmAsRead - The consumer can set an alarm as viewed.

UC: setAlarmAsFalsePositive - Sets the property of an alarm as a false positive.

UC: getPredictions - Gets the predictions of water, gas,...

UC: getMeasurementsQuery - Can do a GETQuery for researchers.

Decomposition Our decomposition will consist out of 3 components. A ConsumerService, a Device-Service and a MeasurementService. Respectively they will handle the incoming requests on the Control-Panel for the consumers (e.g: registration), the management of devices like controlling (e.g: shutdown avalve) the users devices from the ControlPanel and the measurement operations. The components haveaccess to the Storage component for doing queries. This way, the database keeps safe because operationsonly gets to these components if they can pass the safety due to the ServiceLookupTablein the FrontCon-troller as explaind in iteration 18. The first two components have an output to the I/O OutgoingModule.The ConsumerService for sending a mail in case of a user registration. The DeviceService for sendinga command to shutdown a valve or the new configuration if this was changed. The ConsumerServicehas a connection to the UIS so he can notify the UtilityProviderss system when a consumer stops usingReMeS.

Diagrams Here you find the diagrams for this iteration. In figure 39 you can find the figure of thedecomposition tree. The first two components of the Backend are found in figure 40 and figure 41. The

measurementService is similar.

Figure 39: The decomposition tree of the ControlPanels Backend

Figure 40: Component diagram of the ControlPanels Backends ConsumerService

35


36/77

Figure 41: Component diagram of the ControlPanels Backends DeviceService

Functionality Reallo cation If we assume the 2 components have the interfaces to handle all theoperations that have to be done from the ControlPanel. This is too low level to further decompose here.


Uptill now all the components of figure 30 are decomposed. We have:


AlarmComponent - IncomingScheduler: Iteration 2







MeasurementComponent - AnomalyDetection: Iteration 10

Storage: Iteration 11

Storage - MeasurementStorage: Iteration 12

Storage - ConsumerStorage: Iteration 13

Storage - AlarmStorage: Iteration 14

ControlPanel: Iteration 15

ControlPanel - AuthService: Iteration 16

ControlPanel - AuthService - TokenGenerator: Iteration 17

ControlPanel - FrontController: Iteration 18

ControlPanel - Backend: Iteration 19



UC 1: Log in - ControlPanel

UC 2: Log off - ControlPanel

UC 3: Register consumer - ControlPanel

UC 4: Unregister consumer - ControlPanel

UC 5a: Associate device to consumer - ControlPanel

UC 6: Customize consumer profile - ControlPanel

36


37/77

UC 7: Send trame to remote device - Outgoing Module

UC 8: Send measurement - Incoming Module(routing to Measurement)

UC 9: Notify consumer - AlarmComponent & Outgoing Module

UC 10: Detect anomaly - AnomalyDetection

UC 11: Operate actuator remotely - ControlPanel

UC 12: Set alarm recipients - ControlPanel UC 13: Send alarm - AlarmComponent

UC 14: Request consumption predictions - ControlPanel

UC 17: Perform research - ControlPanel



Performance 2: Anomaly Detection - AnomalyDetection

Performance 3: Requests to the measurement database - MeasurementStorage

Availability 1: Measurement database failure - MeasurementStorage



Modifiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modifiability 3: Decentralized electricity generation - IncomingModule

Use cases to do:

UC 5b: Additional connection tests

UC 15,16


Availability 3

Modifiability 1b,2

2.25 Iteration 20: Decomposing the ControlComponent

Components to decompose In the recapitulation of the previous section we see that use case 5bstill needs to be done. When a new device is installed, inital connection tests need to be performed. Inthis section we will add a ControlComponent to the system resulting in figure 42.

Figure 42: Adding the ControlComponent to the system

Architectural Drivers The things needs to be done are:

UC: receiving testTrame

UC: sending testTrame

UC: mark device as active

37


38/77

Decomposition We need a TrameReader to check from which valve the testTrame is coming. Weneed a TestTable to hold the current test status per valve and finally a DbUpdater for updating thedatabase if the valve can be set active after passing the tests. The TestTable could hold the amount ofreceived testTrames per module. After a specified number it could call the DbUpdater to set the moduleas ready. The TestTable has a connection to the I/O OutgoingModule to send additional testTrames.

The incoming testTrames first come in on the I/O IncomingModule of iteration 5. Imagine its likeadding a component ControlComponent beneath the AlarmComponent in figure 8.

Diagrams Here you find the diagrams for this iteration. In figure 43 you can find the figure of thedecomposition tree. The component diagram can be found in figure 44.

Figure 43: The decomposition tree of the ControlComponent

Figure 44: Component diagram of the ControlComponent

Functionality Reallocation Use case UC: 5 Associate device to consumer is now complete. Furtherdecomposition of the ControlComponent isnt necessary.

2.26 Iteration 21: Decomposing the BillingComponent

Components to decompose To deal with the remaining use cases we add a BillingComponent tothe system and decompose it in this iteration. Our new tree becomes like figure 45.

38


39/77

Figure 45: Adding the BillingComponent to the system

Architectural Drivers The drivers are the leftover use cases:

UC 15: Generate invoice

UC 16: Mark invoice paid

Availability 3: Third party billing service failure

Modifiability 1b: Consumer can have a dynamic billing profile.


Ping/echo


We will use the ping/echo tactic to detect a failure of the 3th party billing company. In fact the message

that is send can be the ping. If we ask to the 3th party billing company to acknowledge every sendedmessage than this can play the role of echo. This way we can easily set up a reliable system. The method

with the heartbeat would give us to much overhead. It is also not relevant that the billing system of the3th party is down when you dont want to send messages to it.

A tactic for Modifiability 1b is Anticipate expected changes. We chose this because we think it is easy toaccomplish.

Decomposition The TimeTicker will ask to generate invoices every day to the InvoiceHandler. Thiscomponent will get the consumers which billing date is the current date. For every consumer he will thenask to create an invoice to the InvoiceCreator, who gets the current rates. He will get the measurementsfrom the database for that user and create an invoice. He will add that invoice to the consumer profileand save this. He will also tell the InvoiceSender to send this invoice. When the consumer has paid the

invoice the 3th party billing company will let the listener know that the invoice is paid and the listener

will store that in the database.

To achieve Modifiability 1b only some small modifications to figure 47 should be made because wealready get the rates. We could create a component that continiously gets the new rates, checks whichconsumers have dynamic pricing in their profile (includes a small modification to the controlpanel andbackend so consumers can set this property), check the pricerate with the consumers treshold. Finallya connection to the I/Os OutgoingModule for sending a command to activate a remote smart devicecould be made (or a notification to the consumer for manual intervention). (like said in iteration 4)

We can also take back Modifiability 3: Decentralized electricity generation (introduced in iteration 4and 5) This affects also the billing. If this would be implemented the measurements(usages) can be getfrom the database. But also the consumers generated power can be get from the database(requires only

39


40/77

1 extra request next to getMeasurements in figure 47). Based on those 2 datasets the new billing can bedone.

Diagrams Here you find the diagrams for this iteration. In figure 46 you can find the figure of thedecomposition tree. The component diagram can be found in figure 47.

Figure 46: The decomposition tree of the BillingComponent

Figure 47: Component diagram of the BillingComponent

Functionality Reallocation We will make a further decomposition of the InvoiceSender in the nextiteration. The use cases for that component are:

UC: Send an invoice

UC: wait for an acknowledgement

UC: Resend an message if the acknowledgement isnt received

2.27 Iteration 22: Decomposing the BillingComponents InvoiceSender

Components to decompose In this section we will decompose the InvoiceSender of figure 46 of theBillingComponent.

40


41/77


42/77

3 Final Architecture

3.1 The context diagram

Figure 50: The context diagram of the overall system

In figure 50 you can find the context diagram of the overall system. While designing the system we triedto limit the amount of components that interact directly with the environment. The I/O component is

in charge of handling all the communication. This includes sending the trames to the measurement andcontrol modules and sending an e-mails or sms to notify a consumer. All these different communicationchannels are represented by MessageChannel in the context diagram.

The UIS is beng used by two components the BillingComponent and the ConsumerService. The Billing-Component uses the UIS to get the rates of the consumers so he can make an invoice. He then sends

this invoice to the 3th party billing which explains that connection. Also the ConsumerService needs theUIS to signal that a consumer isnt longer using the ReMeS system.

The last connection is that of the client to the GUI. The GUI is used by the consumers, call centeroperatives and the technicians. This is a webpage that gives commands to the back-end. All the humaninteraction to the system is given through this control panel.

3.2 The Overall system

In figure 51 you can find a component diagram of the overall system. Not all connections are displayedto keep the diagram clear. For detailed connections you can consult the diagrams of the decomposition.All the trames enter the system through the I/O component. This component analysis the type oftrame and redirects it to the right component that will handle it. The AlarmComponent handle all thealarms. It will store this is permanent storage en will act upon it following the configuration settingsof the consumer. The ControlComponent handles all control messages of new modules. When themodules are fully tested he will mark this is the database. This way a technician can see if the moduleis correctly installed. The MeasurementComponent handles all the measurement trames. It will storethese in the database. He will also run anomaly detection algoritmes on the results and send a alarm to

42


43/77

Figure 51: A component diagram of the overall system

the AlarmComponent if necessary. The three previous components also have a connection back to theI/O to send messages but this isnt displayed on the diagram to keep it clear.

43


44/77

The Storage component handles all the databases. It gives an interface to modify consumer, alarm andmeasurement objects. For certain functions it also has replicas to guarantee a good uptime.

The ControlPanel handles all the communication with the users, call center representatives and techni-cians. All the commands the control panel can do are handled by the back-end components who haveaccess to the storage. The connection between the Control Panel and the MeasurementComponent is

necessary when a module has to be deleted. In that case the module has to be deleted from the heartbeattable, otherwise the system would generate an alarm. It also has a connection with the UIS so it caninform the utility providers when a consumer starts or stops using ReMeS. The connection to the I/Ocomponent is for notifying clients

The final component is the BillingComponent. This component handles the generation of the invoicesfor the consumers. It has a connection to the UIS for this so he can get the rates for the consumers.

After creating this invoice he will store it and send it to a 3th party billing company who will handle thelogistic element. When the invoices are paid they will let this know to our system.

In the next system we will decompose these components to clarify their functionality.

3.3 Decomposition diagrams

I/O component This component consists of an incoming and outgoing module. The Incoming modulehandles the incoming trames and sends these to the right component it also sends acknowledgementtrames to the outgoing module who will send it to the measurement modules. The Outgoing modulehandles all the messages that have to be send. This can be done over different media so for every mediathere is a sender who will prepare and send the message.

44


45/77

Figure 52: The decomposition of the I/O component

Alarm component De AlarmComponent handles all the alarms. All alarms enter through the In-coming Scheduler. This scheduler will read the type of the alarm and schedule it. The AlarmHandlerwill repeatedly ask an alarm from the scheduler and handle it. It will handle it by storing the alarm inthe permanent storage and sending an close valve command to the control module if necessary. To knowwhich actions he has to do he asks the configuration from the consumer for that module. The consumercan also be notified if it is listed in the configuration.

45


46/77


47/77

Figure 54: The decomposition of the control component

Measurement Component The MeasurementComponent handles all the incoming measurements.The decomposition isnt complete in this diagram to keep it clear. You can find the decomposition ofTrameHandler, HeartBeatDetector and AnomalyDetection below.

Figure 55: The decomposition of the measurement component

Trame Handler The TrameHandler gets the incoming trames from the buffer. He will create anMeasurementDate object and store it in the database. He will also update the HeartbeatDetector andask the AnomalyDetection component to check for anomalies.

47


48/77

Figure 56: The decomposition of the trame handler

HeartBeatDetector The HeartBeatDetector checks whether a module stops sending trames. TheTrameHandler will update when a message is received and he will also say when the next trame should

be received. This info is stored in the TimeTable. This TimeTable will decrease the time values in histable every minute. The TableAnalyser will than check the table every minute for modules which aremissing a message. He will send this module a trame to make him send a message. If this fails threetimes he will raise an alarm for the AlarmComponent.

Figure 57: The decomposition of the heartbeat detector

Anomaly Detection The AnomalyDetection component will run an algorithm on the new measure-ment data together with older ones which it gets from the database. He will also take into accountprevious alarms. There are multiple instances than run these algorithms at the same time. There is alsoa scheduler because certain consumers get priority over others.

48


49/77

Figure 58: The decomposition of the anomaly detection

Storage The Storage component handles all the databases. All the requests enter the QueryHandlerwho will route it to the correct database. The databases all return an object which than can be read andupdated. To make the transition between objects and the relational databases themselves, a DataMapperis used. The MeasurementStorage is different from the other ones because it has a scheduler to schedulethe requests, multiple Datamappers and a replicated Database.

49


50/77


51/77

Control Panel The ControlPanel component is the only way the system communicates with actualusers. There is a GUI which is a site which is build with basic web technology like HTML and JavaScript.This website contains commands which will be handled by the FrontController. He will redirect thiscommand to the right service in the Backend. Before he will redirect the command he will however firstcheck with the AuthService, if the user is allowed to use this command.

Figure 60: The decomposition of the control panel

Back end The Backend component handles all the command that are transmitted by the controlpanel. To complete this commands he needs information from some other systems. He has a connection

to the Storage to get and update consumers, a connection to the I/O to send messages, a connection tothe UIS to signal the utility provider that a user starts or stops using ReMeS and a connection to theMeasurementComponent to delete a device from the heartbeat table.

Figure 61: The decomposition of the back end

51


52/77


53/77

3.4 Deployment Diagram

In figure 64 you can fiend the deployment diagram of the system. The clients (consumers, call centeroperatives and technicians) use a computer to access the systems control panel. The Control panel ishosted on a webserver. This webserver will than contact the back-end through RMI messages. Becausethe systems in this Back-End are state-less he can be replicated to allow more requests. The Back-Endalso accesses the storage through the Storage Access server. This server handles all the database requestsen route then to the correct database server. On the diagram there is only one database server displayedbut in reality there will be multiple servers that are also replicated.

The I/O server is the server where all messages leave and come in. This server will connect to threedifferent servers that all contain their own component. Again the communication will run through RMI.This three servers, the Measurement server, Control server and Alarm server can also be replicatedbecause they are also stateless. All the states are stored in the storage component. By consequence theonly synchronization that has to be done is in the component.

The final server is the Billing server he will get data from the databases and from the UIS with which

he will build the invoices. The invoices are then sended to the 3th Party Billing company.

All the extern connections arent represented on this diagram because this falls out of the scope forthis system. There has to be a consensus with the UIS and the 3th Party Billing companies for whichprotocols that will be used.

53


54/77

Figure 64: The deployment diagram of the system

54


55/77

4 Scenarios

4.1 User profile creation

Figure 65: The sequence diagram for user profile creation

In figure 65 you can find the sequence diagram for this scenario. The call center operative will fill in aform on the GUI. He will then send a command to the ConsumerService through the FrontController.

The ConsumerService stores the new user and sends an e-mail through the I/O component.

4.2 User profile associations with a remote monitoring module

Figure 66: The sequence diagram for the device association

The consumer can add a device through the control panel. The GUI will then send an add devicecommand to the ConsumerService through the FrontController. The ConsumerService will than createa device profile. He will get the consumer object from the storage and add the device object to the

consumer. He will than store the consumer. This way the device is linked.

4.3 Remote monitoring: Installation and initialization

The device association with the consumer is the same as in the previous section. The only difference isthat we have to handle the first testing frames and flag the device as active. The sequence diagram forthis part of the scenario is displayed in figure 67.

Because the devices are preconfigure to send trames the I/O will receive these and redirect them to theControlComponent. This component will send a trame asking for more details are mark the device asready. He does this by getting the consumer object in which the device object is located. He finished bystoring the consumer again in the storage.

55


56/77


57/77

Figure 69: The sequence diagram for the heartbeat system

4.6 Remote monitoring: Alarm notification recipient configuration

This scenario has the same actions in the system than the scenario in section 4.4. The only difference isthat the DeviceService doesnt send a message to the I/O component because the module doesnt haveto be notified of the change.

4.7 Remote control

The first section of the scenario can be completed the same way as the installation of the measurementmodule in section 4.3. The only difference is that the GUI doesnt call addModule but addActuatorso the actuator is coupled with the measurement module. The sequence diagram for this part of thescenario is displayed in figure 70.

Figure 70: The sequence diagram for linking of the actuator

The second part of the scenario is the same as section 4.6. Because when the GUI calls changeDevice-Config the DeviceService will detect whether the id is of a measurement module or a actuator and updatethe configuration in the consumer object accordingly.

4.8 Normal measurement data transmission

The sequence diagram for this scenario is displayed in figure 71. The I/O adds the trame to a buffer.The TrameReader will get the trame when hes ready. He will then create a MeasurementData objectand store it in the database.

57


58/77


59/77

Figure 73: The sequence diagram for the planning production

deep.

4.12 Alarm data transmission: remote monitoring module

Figure 74 contains the sequence diagrams for handling alarms. The I/O will store the requests in theIncomingScheduler. This Scheduler will schedule the alarms according to type. The Tramereader willhandle the next alarm when he is ready. He will get the module configuration from the ConsumerInfowho will also notify the consumer and emergency services. The TrameReader will than close the valve ifnecessary according to the configuration. If he closes the valve he will change the status of this valve inthe storage. He will also store the alarm in the storage.

4.13 Alarm data transmission: ReMeS

In section 4.9 we already described how we detect anomalies inside the ReMeS system and how we raisean alarm in this case. Our system will assume that all alarms are correct except when a user marks

it as a false positive. You can find the sequence diagram for this action in figure 75. The user willmark the alarm as a false positive in the control panel. The GUI will then pass this command to theConsumerService through the FrontController. This component will get the alarm from storage, mark itas false and store it again. The anomaly detection algorithm takes all the alarms into account includingthese false positives. In this design we dont save individual consumption patterns.

4.14 Remote control module de-activation

In figure 76 you can find the sequence diagram for deactivating modules. The user will use the controlpanel to do the deactivation. The GUI will pass the command to the DeviceService through the Front-Controller. The DeviceService will then get the consumer object from the storage and delete the device.

The consumer object is then stored again. He will also send a message to the MeasurementComponentto delete the device from the hearbeat table otherwise false alarms would be generated.

4.15 New bill creation

In 77 you can find the sequence diagram for creating new invoices. The Timeticker will ask the In-voiceHandler to generate the invoices for the people which billing month ends the current day. TheInvoiceHandler will get these consumers from the storage. For every consumer he will then run thecreate invoice command on the InvoiceCreator. This component will then get the measurements forthat user and his rate from the UIS. He will then create the invoice. The invoice will be sent with the

59


60/77


61/77

Figure 74: The sequence diagram for the handling of alarms

61


62/77


63/77

Figure 78: The seque

Documents

Software Architecture Project 2