Building the Object Model
According to the steps defined to obtain the object model, we have:
1. Identification of the objects: The objects identified in the model are the sensors BDSensor_RT1 and BDSensor_RT2, and the real-time database server, called BDWarehousing.
2. Identification of relationships among objects: The sensors send data to the server through transactions. Each sensor updates the server, while the server is updated by various sensors.
3. Addition of attributes to objects: The data item X acquired by the sensor is composed of the following attributes: Value is the content of data item; avi is the absolute validate interval; timestamp is the late update time; and sensor identifies which sensor acquired the data. The attributes of the data item stored in the real-time database server has the fields: Tp, which is the data item processed; Qtde, which is the value that will be updated in the server; Avi, which is the absolute validate interval; Tsp, which is the late update time; sensor, which identifies the sensor that acquired the data; Imp, which is the accumulated imprecision; and Milr, which is the limit of Imp.
4. Use of generalization to observe similarities and differences: This step is unnecessary for this model, due to existence of only two objects.
Figure 5. Architecture of the sensor network case study
Environment
5. Identification of operations: The sensors aim at acquiring data of the external environment (method AT) and these data can be read by long and snapshot queries (method CTL and method CTI, respectively). Long queries are performed in a time interval, and snapshot queries are performed in an absolute time. The real-time database server has historical data obtained by sensors (method AT), and allows one to query this historical data (method CTH).
6. Identification of concurrent operations: The BDSensor_RT1 and BDSensor_RT2 object has two negotiation functions that represent two different types of concurrency. The first situation is observed when the data item is being acquired and a query is invocated. The second situation of concurrency is possible when a query is running and an acquisition operation begins. In the BDWarehousing, three negotiation functions define the concurrence between the transactions.
Besides the situations defined to the sensors, it is possible that two update operations try to access the same data item, where the sensor is updating the item and an applicative program is changing this data.
7. Identification of both logical and temporal constraints: In the sensor, the con-straints defined to the data are: The type and the absolute validity interval of them.
Figure 6. Object model
The constraints defined to the server are: the type of data item and the performance metrics Pt and Impr, described in this chapter.
The QoS management is performed by the functions: specification, mapping, and monitoring, in addition to the negotiation function defined for the objects. Figure 6 illustrates the object model for the case study.
Building the Process Model
According to the steps defined to obtain the process model, we have:
1. Identification of the objects in HCPN: In this first step, the objects are identified from the object model for the the HCPN modules.
2. Identification of functions for each object: The sensor object implements the mechanisms of acquisition and stored data, besides reading the content stored.
The real-time database server object implements the update and reading of the database.
3. Definition of interface for each object: In the HCPN module of sensor, the interface is defined by the methods: AT, CTL, and CTI and by attribute X that represents a record. The interface of the HCPN module to the server object indicates the methods AT and CTH and the attribute DB that represent a record with the fields defined to the data item stored in the server.
4. Definition of internal structure for each object: The internal structure is a hierarchical coloured Petri net to model the methods declared in the interface of the object.
The overview of the process model is illustrated in Figure 7. The HCPN modules are:
• Declaration: This represents the declarations, that is, the functions, types, and so on.
• BDWarehousing: It is the database server.
• Negotiation1 and Negotiation: This represents the negotiation functions.
• Specification: It is the module where the temporal parameters are specified.
• Sensor1, Sensor2, and Sensor3: This represents the modules for sensors.
• UpdateS1, UpdateS2, and UpdateS3: These are the sensors’ transactions that update the server.
• MonitoringS1, MonitoringS2, and MonitoringS3: They are the monitoring func-tions related to each sensor transaction.
• Update and MonitoringUp: These modules are for the update transaction (only read) and the monitoring function defined for it.
• Active and Performance: These are control modules.
Generating the Occurrence Graph
For the real-time database modeled, the full standard report follows. According to the report, we have the full generation in 47 seconds, with 6,713 nodes and 22,867 arcs.
Statistics
--- Occurrence Graph
Nodes: 6,713 Arcs: 22,867 Secs: 47 Status: Full
Some places are shown in the boundedness properties. The place ObjetoBD’ObjetoBDP represents the repository of data and it has the limit of 1 token. Two different combina-tions to the token in this place are represented in report.
Boundedness Properties
--- Best Integers Bounds Upper Lower ObjetoBD'ObjetoBDP 1 1 1 Best Upper Multi-set Bounds
ObjetoBD'ObjetoBDP 1 1`{nr = t1,vrr = 10,avir = 10,tsr = 33,impr = 1,milr = 8}++ 1`{nr = t1,vrr = 10,avir = 10,tsr = 39,impr = 1,milr = 8}
In liveness properties, we have 24 dead markings, that is, there are 24 different ways to the net stopping. In relation to dead transition, there is only one Figure 7. Process model
Menu
Hierarchy Declaration Active Performance
Negotiation1 Negotiation2
BDWarehousing Database Server
Specification
UpdateS1 UpdateS2 UpdateS3 Update
MonitoringS1 MonitoringS2 MonitoringS3 MonitoringUp
ReturnS1 ReturnS2 ReturnS3 ReturnTS1
Sensor1 Sensor2 Sensor3 sensor1 sensor2 sensor3
FCObjetoBDLeAt’AvaliaFCLeAt. This transition is dead, since neither conflict occurred when a read transaction was executing and a write transaction was invocated.
Liveness Properties
--- Dead Markings: 24 [6713,6712,6711,6710,6703,...]
Dead Transitions Instances: FCObjetoBDLeAt'AvaliaFCLeAt 1
Generating the Message Sequence Chart
In Figure 8, we have the MSC generated considering the scenario with two sensors acquiring the same data item.
• Sensor1: writes periodically in the local database, the release time is 1 time unit (t.u.) and the period is 3 t.u.
• Sensor2: writes periodically in the local database, the release time is 9 t.u., and the period is 9 t.u.
Moreover, there are two write transactions and one read transaction.
Figure 8. Message sequence chart
• Update 1: Periodically updates the database server object with respect to the data in Sensor1. The release time is 3 t.u., the computational time is 2 t.u., the deadline is 12 t.u., and the period is 12 t.u.
• Update 2: Periodically updates the database server object for sensor2. The release time is 9 t.u., the computational time is 4 t.u., the deadline is 18 t.u., and the period is 18 t.u.
• Query: Periodically queries the real-time database-server application. The release time is 3 t.u., the computational time is 6 t.u., the deadline is 12 t.u., and the period is 12 t.u.
The release time is the moment when all the necessary resources to the execution of the transaction and sensors are available. Starting from this moment the transaction will be ready to be executed. The computation time is the processing time necessary to execute it. The deadline defines the maximum transaction execution period. Finally, the period defines the periodicity of the transaction and sensor.
In the MSC, it is also possible to verify the QoS functions, where the negotiation between transactions conflicting and the time properties are visible during whole lifetime of a system.
Generating the Timing Diagram
In Figure 9, the timing diagram for the execution of transactions and sensors is presented.
In this figure, it is possible to see a representation of the timing model execution for both transactions and sensors, where the execution is represented by rectangles.
In the vertical axis, the transactions and the sensors are represented. In the horizontal axis the release time and the periods for both, transactions and sensors, and computa-tional times and deadline for transactions are represented. For each transaction, we consider three states: start; processing, and committing. The start of the execution of
Figure 9. Timing diagram
Frequency and Time of Transactions Execution
Update/Query/Sensors
a transaction is illustrated by a dotted line rectangle. The processing is represented by a filled rectangle, and the committing by a continuous line rectangle. For the sensor, we only show the state processing.
In the vertical axis, the Update 1 transaction is represented in 1. The Update 2 transaction is represented in 2. The Query transaction is represented in 3. The sensor1 is represented in 4, and the sensor2 in 5.