Formal Verification of Models for M2M Device...

16
Formal Verification of Models for M2M Device Registration Evelina Pencheva 1 , Ivaylo Atanasov 1 and Anastas Nikolov 1 Abstract – Device management is a challenging task in Machine-to-Machine (M2M) communications. The increased number of connected devices and device diversity calls for device management that reduces the deployment time and operational costs. Open Mobile Alliance specified Lightweight M2M protocol for device management. In this paper, we propose device registration models based on Lightweight M2M procedures and a mathematical approach to behavior verification. Both server and client models are formally described, and a concept of weak bisimulation is used to prove that the models are synchronized. Keywords – Device management, Finite state machines, Behavioral equivalence, Weak besimulation I. INTRODUCTION Machine-to-Machine (M2M) communications have various application areas such as automotive, home automation, smart cities, energy efficiency, industry, agriculture, safety and security, health, education and others. Despite the differences all these areas set common requirements for connected devices to communicate through different access networks, remote configuration and control. Device management is a challenging and critical issue due to rapidly growing number of connected devices and their diversity [1]. A plethora of devices and customized solutions are available on the market and a large amount of the employed technology is proprietary today [2], [3], [4]. This calls for abstraction of device management functions which has to hide the complexity and to be technology independent. Such an abstraction can be provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol from the Open Mobile Alliance for M2M device management. It defines device management procedures between a LWM2M server and a LWM2M client, which is located in a device. The protocol may be used to create device management solutions that apply the approach of software defined networks [7], [8]. The proposed solutions, based on LWM2M, consider high level architectural aspects and do not provide details on behavioral models that follow the M2M device management procedures. In this paper, we suggest an approach to formal verification of LWM2M server and client behaviour related to device management. Our models are compliant with ETSI M2M functional architecture [9] and Enabler Test Specification for Lightweight M2M [10]. First we start with formal description of device registration models and using the well known concept of weak bisimulation [11] we prove formally that the models are synchronized. In addition to regular device registration functions, our models include functions related to server initiated device registration, updating the firmware version and server disabling, and prove that the models expose equivalent behaviour. II. DEVICE REGISTRATION MODELS Device registration allows the server to maintain device reachability status. If the device is not registered it is not reachable. When the device sends a registration request (reg req ) it moves to registering state, where it awaits the server answer. After receiving the server answer with registration acknowledgement, the device sets the registration timer (Treg) and moves to registered state. If the device is registered, it is with operational firmware and the server and device store registration-related information making it available, on request or based on subscription. When the registration timer expires the device refreshes it registration. When registered, the device may receive a soft offline request and then it sends a de-registration request to the server and becomes unregistered. The device’s view point on its registration state is as follows. In Unregistered D state, the device is offline and it is not registered. In Registering state, the device is in a process of registration. In OperationalFw D , the device is registered with operational firmware. In UpdateRegistration state a transport binding between the server and device is established and the device waits for registration update trigger message from the server. In WaitDeregAck state, the device waits for de-registration acknowledgement. In FirmwareDownloading D state, the device downloads the new firmware version. The model representing the device’s view on its registration state is shown in Fig.1. The server’s view point on device registration state is as follows. In Unregistered S state, the device is not registered. In OperationalFw S state, the device is registered with operational firmware. In NotificationStoring state, the device is registered and the server updates the notification storing object. In Disabling state, the server will be disabled. In Transport- Binding state, the device is registered and updates the registration. In WaitUpdateAck state, the server waits for acknowledgement of transport binding. In WaitFwVersion state, the device is registered and the server reads the current firmware version. In WaitDownlodAck state, the device is registered and the server initiates the download of a new firmware version. In FirmwareDownloading S state, the device downloads the new firmware version. In WaitFwActionStatus state, the server asks for the firmware downloading status. In WaitFwUpdate state, the server waits for acknowledgement of 1 The authors are with the Faculty of Telecommunications at Technical University of Sofia, 8 Kl. Ohridski Blvd, Sofia 1000, Bulgaria, E-mails: [email protected]; [email protected]; [email protected]

Transcript of Formal Verification of Models for M2M Device...

Page 1: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

Formal Verification of Models for M2M Device Registration

Evelina Pencheva1, Ivaylo Atanasov1 and Anastas Nikolov1

Abstract – Device management is a challenging task in Machine-to-Machine (M2M) communications. The increased number of connected devices and device diversity calls for device management that reduces the deployment time and operational costs. Open Mobile Alliance specified Lightweight M2M protocol for device management. In this paper, we propose device registration models based on Lightweight M2M procedures and a mathematical approach to behavior verification. Both server and client models are formally described, and a concept of weak bisimulation is used to prove that the models are synchronized.

Keywords – Device management, Finite state machines, Behavioral equivalence, Weak besimulation

I. INTRODUCTION

Machine-to-Machine (M2M) communications have various application areas such as automotive, home automation, smart cities, energy efficiency, industry, agriculture, safety and security, health, education and others. Despite the differences all these areas set common requirements for connected devices to communicate through different access networks, remote configuration and control. Device management is a challenging and critical issue due to rapidly growing number of connected devices and their diversity [1]. A plethora of devices and customized solutions are available on the market and a large amount of the employed technology is proprietary today [2], [3], [4]. This calls for abstraction of device management functions which has to hide the complexity and to be technology independent. Such an abstraction can be provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol from the Open Mobile Alliance for M2M device management. It defines device management procedures between a LWM2M server and a LWM2M client, which is located in a device. The protocol may be used to create device management solutions that apply the approach of software defined networks [7], [8]. The proposed solutions, based on LWM2M, consider high level architectural aspects and do not provide details on behavioral models that follow the M2M device management procedures. In this paper, we suggest an approach to formal verification of LWM2M server and client behaviour related to device management. Our models are compliant with ETSI M2M functional architecture [9] and Enabler Test Specification for Lightweight M2M [10]. First we start with formal description of device registration models

and using the well known concept of weak bisimulation [11] we prove formally that the models are synchronized. In addition to regular device registration functions, our models include functions related to server initiated device registration, updating the firmware version and server disabling, and prove that the models expose equivalent behaviour.

II. DEVICE REGISTRATION MODELS

Device registration allows the server to maintain device reachability status. If the device is not registered it is not reachable. When the device sends a registration request (regreq) it moves to registering state, where it awaits the server answer. After receiving the server answer with registration acknowledgement, the device sets the registration timer (Treg) and moves to registered state. If the device is registered, it is with operational firmware and the server and device store registration-related information making it available, on request or based on subscription. When the registration timer expires the device refreshes it registration. When registered, the device may receive a soft offline request and then it sends a de-registration request to the server and becomes unregistered.

The device’s view point on its registration state is as follows. In UnregisteredD state, the device is offline and it is not registered. In Registering state, the device is in a process of registration. In OperationalFwD, the device is registered with operational firmware. In UpdateRegistration state a transport binding between the server and device is established and the device waits for registration update trigger message from the server. In WaitDeregAck state, the device waits for de-registration acknowledgement. In FirmwareDownloadingD state, the device downloads the new firmware version. The model representing the device’s view on its registration state is shown in Fig.1.

The server’s view point on device registration state is as follows. In UnregisteredS state, the device is not registered. In OperationalFwS state, the device is registered with operational firmware. In NotificationStoring state, the device is registered and the server updates the notification storing object. In Disabling state, the server will be disabled. In Transport-Binding state, the device is registered and updates the registration. In WaitUpdateAck state, the server waits for acknowledgement of transport binding. In WaitFwVersion state, the device is registered and the server reads the current firmware version. In WaitDownlodAck state, the device is registered and the server initiates the download of a new firmware version. In FirmwareDownloadingS state, the device downloads the new firmware version. In WaitFwActionStatus state, the server asks for the firmware downloading status. In WaitFwUpdate state, the server waits for acknowledgement of

1The authors are with the Faculty of Telecommunications atTechnical University of Sofia, 8 Kl. Ohridski Blvd, Sofia 1000,Bulgaria, E-mails: [email protected]; [email protected];[email protected]

Page 2: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

firmware update. In RemoveOldFirmware state, the server waits for acknowledgement that the old firmware version is removed. In Rebooting state, the server waits device rebooting. The model representing the server’s view on device registration state is shown in Fig.2.

III. FORMAL MODEL VERIFICATION

Both models are formally described as Labeled Transition Systems (LTS).

By RD= (SD, АctD, →D, s0D) it is denoted an LTS

representing the authorized device’s view on its registration state, namely: SD = { UnregisteredD, Registering, OperationalFwD,

UpdateRegistration, FirmwareDownloadingD, WaitDeregAck };

ActD = { online, Tdisable, initialRegack, reRegack, fwVersionreq, removeFwreq, updateNSreq, TregD, bindreq, updateRegcom, disablereq, rebootreq, writeFwreq, readFwreq, updateFwreq, softOffline, deRegack };

→D = { D1τ , D

2τ , D3τ , D

4τ , D5τ , D

6τ , D7τ , D

8τ , D9τ , D

10τ , D11τ , D

12τ , D13τ , D

14τ , D15τ , D

16τ , D17τ }

s0D = { UnregisteredD },

where D

1τ = (UnregisteredD online Registering) D2τ = (UnregisteredD Tdisable Registering) D3τ = (Registering initialRegack OperationalFwD) D4τ = (Registering reRegack OperationalFwD) D5τ = (OperationalFwD fwVersionreq OperationalFwD) D6τ = (OperationalFwD removeFwreq OperationalFwD) D7τ = (OperationalFwD updateNSreq OperationalFwD) D8τ = (OperationalFwD TregD Registering) D9τ = (OperationalFwD bindreq UpdateRegistration) D

10τ = (UpdateRegistration updateRegcom Registering) D

11τ = (OperationalFwD disablereq UnregisteredD) D

12τ = (OperationalFwD rebootreq Registering) D

13τ = (OperationalFwD writeFwreq FirmwareDownloadingD) D

14τ = (FirmwareDownloadingD readFwreq FirmwareDownloadingD)

D15τ = (FirmwareDownloadingD updateFwreq OperationalFwD) D

16τ = (OperationalFwD softOffline WaitDeregAck) D

17τ = (WaitDeregAck deRegack UnregisteredD). By RS= (SS, АctS, →S, s0

S) it is denoted an LTS representing the server’s view on authorized device registration state as follows: SS = { UnregisteredS, OperationalFwS, TransportBinding,

NotificationStoringS, Disabling, WaitUpdateAck,

WaitFwVersion, Rebooting FirmwareDownloadingS, WaitFwActionStatus, WaitFwUpdate, WaitDown-loadAck, RemoveOldFirmware, };

ActS = { initialRegreq, reRegreq, TregS, deRegreq, notifStoring, updateNSack, disable, fwAvailable, updateReg, disableack, bindack, updateRegack, fwVersionres, writeFWres, fwTdl, readFwres, updateFwack, removeack, rebootack } →S ={ S

1τ , S2τ , S

3τ , S4τ , S

5τ , S6τ , S

7τ , S8τ , S

9τ , S10τ , S

11τ , S12τ , S

13τ , S14τ , S

15τ , S16τ , S

17τ , S18τ , S

19τ , S20τ , S

21τ }; - s0

S = { UnregisteredS }, where

S1τ = (UnregisteredS initialRegreq OperationalFwS) S2τ = (UnregisteredS reRegreq OperationalFwS) S3τ = (OperationalFwS reRegreq OperationalFwS) S4τ = (OperationalFwS TregS UnregisteredS) S5τ = (OperationalFwS deRegreq UnregisteredS) S6τ = (OperationalFwS notifStoring NotificationStoringS) S7τ = (NotificationStoringS updateNSack OperationalFwS) S8τ = (OperationalFwS disable Disabling) S9τ = (OperationalFwS fwAvailable WaitFwVersion) S10τ = (OperationalFwS updateReg TransportBinding) S11τ = (Disabling disableack UnregisteredS) S12τ = (TransportBinding bindack WaitUpdateAck) S13τ = (WaitUpdateAck updateRegack UnregisteredS) S14τ = (WaitFwVersion fwVersionres WaitDownloadAck) S15τ = (WaitDownloadAck writeFWres

FirmwareDownloadingS) S16τ = (FirmwareDownloadingS fwTdl WaitFwActionStatus) S

17τ = (WaitFwActionStatus readFwres FirmwareDownloadingS)

S18τ = (WaitFwActionStatus readFwres WaitFwUpdate) S19τ = (WaitFwUpdate updateFwack RemoveOldFirmware) S20τ = (RemoveOldFirmware removeack Rebooting)

S21τ = (Rebooting rebootack UnregisteredS).

Intuitively, in terms of observed behavior, two state machines have bisimilar relation if one state machine displays a final result and the other state machine displays the same result [11]. Strong bisimilarity requires existence of homomorphism between transitions in both state machines. In practice, strong bisimilarity puts strong conditions for equivalence which are not always necessary. For example, internal transitions can present actions, which are internal to the system (i.e. not observable). In weak bisimilarity, internal transitions can be ignored. The concept of weak bisimilarity is used to study the modeling aspects of M2M device registration.

Page 3: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

OperationalFwD

UnregisteredD

Registering

WaitDeregAck

FirmwareDownloadingD

UpdateRegistration

online, Tdisable/initialRegreq, reRegreq

initialRegack, reRegack/ set(TregD)

rebootreq/rebootack, reRegreq, reset(TregD)

TregD/reRegreq

writeFwreq/writeFwack

updateFwreq/updateFwack

readFwreq/readFwack

bindreq/bindack

updateRegcom/updateRegack, reRegreq, reset(TregD)

fwVersionreq/fwVersionackremoveFwreq/removeFwackupdateNSreq/updateNSack

softOnline/deRegreq

deRegack/reset(TregD)

disablereq,/ disableack, set(Tdisable)

Fig. 1. Registration state of an authorized device as seen by the device

UnregisteredS

OperationalFwS

WaitFwVersion

WaitDownloadAck

FirmwareDownloadingS

WaitFwActionStatus WaitFwUpdate

RemoveOldFirmware

Rebooting

NotificationStoringS

Disabling

UpdateBinding

WaitUpdateAck

initialRegreq,reRegreq/initialRegack,reRegack, set(TregS)

fwAvailable/fwVersionreq

reRegreq/reRegack,set(TregS)

disable/disablereq

disableack/reset(TregS)

fwVersionres/ writeFwreq

notifStoring/updateNSreq

updateNSack

updateReg/ bindreq

bindack/updateRegcom

updateRegack/ reset(TregS)

writeFWres / set(fwTdl)

fwTdl/ readFwreqreadFwres/ set(fwTdl) updateFwack/removeFwreq

removeFwack/rebootreq

readFwres/updateFwreq

rebootack/reset(TregS)

1

1

Fig. 2. Registration state of an authorized device as seen by the server

Page 4: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

Proposition: The labeled transition systems RS’ and RD’ are

weakly bisimilar. Proof: Let UR’S’ = {(UnregisteredD, UnregisteredS),

(OperationalFwD, OperationalFwS)}. Then:

1. For initial registration: UnregisteredD {D

1τ , D3τ }

OperationalFwD ∃ UnregisteredS { S1τ } OperationalFwS;

2. For re-registration after offline: UnregisteredD {D

1τ , D4τ }

OperationalFwD ∃ UnregisteredS { S1τ } OperationalFwS;

3. For de-registration: OperationalFwD {D

11τ , D17τ }

UnregisteredD ∃ OperationalFwS {S5τ }UnregisteredS;

4. For re-registration due to registration lifetime is over: OperationalFwD {

D8τ , D

4τ } OperationalFwD

∃OperationalFwS{ S3τ , S

4τ , S2τ }OperationalFwS;

5. For update notification storing: OperationalFwD

{ D7τ }OperationalFwD ∃OperationalFwS {

S6τ , S

7τ } OperationalFwS;

6. For server disabling: OperationalFwD {D

11τ }UnregisteredD ∃

OperationalFwS {S8τ , S

10τ }UnregisteredS; 7. For re-registration when server enables: UnregisteredD

{ D2τ , D

4τ } OperationalFwD ∃ UnregisteredS

{ S2τ }OperationalFwS;

8. For update registration trigger: OperationalFwD {D9τ , D

10τ , D4τ } OperationalFwD ∃OperationalFwS {

S10τ ,

S12τ , S

13τ , S2τ }OperationalFwS;

9. For update firmware version: OperationalFwD {D5τ ,

D13τ , D

14τ , D15τ , D

12τ , D4τ } OperationalFwD

∃OperationalFwS {S9τ ,

S14τ , S

15τ , S16τ , S

17τ , S18τ , S

19τ , S20τ , S

21τ , S2τ } OperationalFwS.

Therefore RS and RD are weakly bisimilar, i.e. they expose equivalent behavior.

IV. CONCLUSION

The paper presents models of M2M device registration status as viewed by the server and by the device. Starting with regular models representing just registered and unregistered device state, we expand the models with additional functionality including server triggered registration update, firmware version update and server disabling. We describe models formally and prove the model synchronization by using the concept of weak bisimilarity. The models are applicable to Device Reachability, Addressing and Repository Service Capability which allows re-use in different M2M applications.

REFERENCES

[1] A. Sehgal, V. Perelman, S. Kuryla, J. Schönwälder. Management of Resource Constrained Devices in the Internet of Things,” IEEE Communications Magazine, December 2012, pp.144-149.

[2] V. Tayur, R. Suchithra. “Software Defined Unified Device Management for Smart Environments,” International Journal of Computer Applications, 2015, vol. 121, issue 9, pp.30-34.

[3] D. Schulz, R. Gitzel, “Seamless maintenance - Integration of FDI Device Management & CMMS,” IEEE Conference on Emerging Technologies & Factory Automation (ETFA), 2013, pp.402-407.

[4] C.S. Shih. C. T. Chou, K. J. Lin, B. L. Tsai, C. H Lee, D. Cheng, C. J. Chou “Out-of-Box Device Management for Large Scale Cyber-Physical Systems,” IEEE International Conference on Internet of Things (iThings), and Green Computing and Communications (GreenCom), and Cyber, Physical and Social Computing (CPSCom), 2014, pp.402 – 407.

[5] V. Cackovic, Z. Popovic. “Device Connection Platform for M2M communications,” IEEE International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 2012, pp.1-7. Software, Telecommunications and Computer Networks (SoftCOM), 2012, pp.1-7.

[6] G. Klas, F. Rodermund, Z. Shelby, S. Akhouri, J. Höller, “Lightweight M2M: Enabling Device Management and Applications for the Internet of Things,” 2014, Available at: http://archive.ericsson.net/service/internet/picov/get?DocNo= 1/28701-FGB101973.

[7] S. Datta, C. Bonnet, “Smart M2M Gateway Based Architecture for M2M Device and Endpoint Management,” IEEE International Conference on Internet of Things (iThings), and Green Computing and Communications (GreenCom), and Cyber, Physical and Social Computing (CPSCom), 2014, pp.61-68.

[8] A.A. Corici, R. Shrestha, G. Carella, A. Elmangoush, R. Steinke, T. Magedanz. “A solution for provisioning reliable M2M infrastructures using SDN and device management,” International Conference on Information and Communication Technology (ICoICT), 2015, pp.81-86.

[9] ETSI TS 102 690 “Machine-to-Machine communications (M2M); Functional architecture,” v1.1.1, 2011.

[10] Open Mobile Alliance, “Enabler Test Specification for Lightweight M2M Candidate Version 1.0 – 03 Feb 2015,” OMA-ETS-LightweightM2M-V1_0-20150203-C

[11] L. Fuchun, Z. Qiansheng, C. Xuesong, “Bisimilarity control of decentralized nondeterministic discrete-event systems,” International Control Conference CCC, 2014, pp.3898-3903

Page 5: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

Autonomous Agent Model for Connectivity Management in M2M Communications

Ivaylo Atanasov1, Anastas Nikolov1 and Evelina Pencheva1

Abstract – The large amount of diverse connected devices which interact with the environment without human intervention and the variety of Machine-to-Machine (M2M) applications is a real challenge for network operators. Embedding autonomic features in M2M system may reduce the operational cost. In this paper, we present a model of autonomous agent for connectivity management of M2M devices. The agent observes connectivity parameters of the device and based on operator policies determines the best bearer that has to be used by the device. Temporal logic is used to formalize the agent behaviour.

Keywords – Remote device management, Network bearer control, Autonomic behaviour, Temporal logic

I. INTRODUCTION

The ubiquitous penetration of Machine-to-Machine (M2M) communications in different application area, the increased amount of equipment and the explosion of M2M services become business and technical challenges for network operators [1]. The reduction of network management complexity can be achieved by embedding autonomic features in operation support systems [2]. The autonomic system exposes reactive or proactive behavior based on external stimuli, following goals that are required to fulfill, policies, capabilities, principles of operation, experience and knowledge.

Currently, there is a lot of work conducted on autonomics by the research community. In [3], the authors discuss challenges and enablers that allow connected machines to evolve and act in a more autonomous way and propose architectural approach based on situational knowledge acquisition and analysis techniques in order to make machines aware of conditions and events affecting systems behavior. In [4], the authors propose a middleware architecture that connects the appropriate devices and applications, and is based on software agents representing devices and applications negotiating between each other on the terms by which the data can be used. In [5], the authors propose network architecture for remote monitoring and surveillance M2M networks with broadband satellite connection. In [6], it is proposed a flexible multi-agent approach, leveraging semantic-based resource discovery and orchestration for home and building automation applications. In [7], a generic architecture for multi-goal, adaptable and open autonomic systems, exemplified via the development of a concrete autonomic application for the smart micro-grid is proposed.

While presenting high level architectural aspects of autonomous systems, these works discuss proprietary solutions and do not consider autonomics in generic M2M communications.

In this paper, we present a model of autonomous agent for connectivity management in M2M communications. The goal of the agent is to optimize the device connectivity parameters by choosing the best bearer that device should use, which is based on device location and device operator policy. First we describe the logic behind the autonomous connectivity management. Next, an overview on the knowledge base in the domain is presented. The conclusion summarizes the contribution.

II. M2M CONNECTIVITY MANAGEMENT AUTONOMOUS AGENT

An agent is a thing that perceives from and acts on an M2M device in such way that the device goes through a sequence of states maximizing the performance measures. The problem in M2M self-optimization includes a goal and set of means to achieve the goal. One of the goals of M2M self-optimization is the usage of the best network bearer. An agent dedicated to M2M self-optimization (Connectivity Management Agent) reasons about and follows actions in order to achieve the goal. The process of reasoning what means it can do is called search. The Connectivity Management Agent is goal-based and solves the problem deciding what to do by finding sequences of actions that lead to the desirable operational state of M2M devices with cellular or wireless connectivity. Further we consider M2M devices with cellular or wireless connectivity. The agent actions can be viewed as transitions between M2M device states.

The problem solving of an M2M Connectivity Management Agent includes four stages: goal formulation, problem formulation, searching solution and execution. The Agent explores the current situation and draws the goal which helps to organize behavior by rejecting actions that result in a failure to achieve the operational state of the M2M device. The Agent draws the problem by deciding what transitions and states to consider following the operational state of M2M device. In general, an M2M Connectivity Management Agent faces with several options of possible sequences of actions because it does not know enough about the current device state. For example, there may be different reasons for device not answering (a connectivity problem, low battery level, a firmware failure, etc.). The Agent searches the solution space by examining different sequences of action. Once the solution is found, the agent carries out the identified actions in the execution stage.

The autonomous behavior of the proposed Connectivity Management Agent is based on the OMA Lightweight M2M

1The authors are the Faculty of Telecommunications at TechnicalUniversity of Sofia, 8 Kl. Ohridski Blvd, Sofia 1000, Bulgaria, E-mails: [email protected][email protected];[email protected]

Page 6: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

(LWM2M) [8]. LWM2M is a standard for a communication mechanism between M2M devices and M2M server platforms. The main motivation behind it is to reduce the degree of fragmentation in the area of M2M remote management.

The LWM2M defines a protocol between M2M devices in a role of clients and the server. The server is responsible for device registration and deregistration, firmware updates, device rebooting, monitoring connectivity parameters on the device, controlling bearers used by the device, configuration of APN and retrieval of device location data [9].

The Connectivity Management Agent in a role of LWM2M server is responsible for device registration, observation of device connectivity parameters and selection of best bearer for the device. The agent functionality for device registration is simplified due to space restrictions and to the facts that the focus is on bearer control.

We assume that the device operator has determined preferred bearers for both specific and normal areas. Each device supports traps, which means that the device is capable of monitoring the event and send notifications whenever it detects the event. The Connectivity Management Agent has to register for the capability in order to use it. OMA DiagMon Trap Events specification defines a number of standardized traps [10]. Geographic trap goes to active when a device enters into a specific geographic area. Whenever the device leaves that specific geographic area, the trap goes to inactive. Collection of measurement data (e.g. signal strength and quality) is important for the connectivity management when the device communicates over the wireless network. Received power trap can help the connectivity optimization process by triggering the Connectivity Management Agent when the received power of the device drops below the server-specific value. Whenever a device’s received power drops below an agent-specified value (TrapActivePower), it causes this trap to go active. Alternatively, when device senses power rises above another agent-specified value (TrapInactivePower), it causes this trap to go inactive. In cases that the trap goes active or inactive, the device notifies the registered agent. The device can have several instances of this kind of trap to monitor various network types (e.g. WiFi, WCDMA, LTE etc). At any time the agent can query the device about its location and about the connectivity parameters, i.e. parameters include the used network bearer, available network bearers, signal strength as well as network identities.

Usually, the goal of Connectivity Management Agent is that the managed device to use the best networks bearer. One of the policies of choosing the best network bearer is as follows. If the device is in the specified area and the signal strength of the preferred bearer in area is higher than the specified value of TrapActivePower, then the best bearer is the preferred one for this area. When the device is out of the specified area and the signal strength of the preferred bearer out of area is higher than the specified value of TrapActivePower, then the best bearer is the preferred out of area one. If the signal strength of the preferred bearer is lower than the specified value of TrapActivePower, then the best bearer is the available bearer with highest signal strength.

The logic behind the Connectivity Management Agent behavior might be described as a temporal sequence. On successful device registration, the agent configures geographic traps and received power traps. The agent queries the device about its location and about connectivity parameters. Based on the location, the signal strength of the used network bearer and available bearers, and the best bearer policy the agent performs a bearer selection procedure for the device. After selecting the best bearer the device is in operational state. During this state, the device may send notifications about traps in case the respective event occurs and the agent performs the bearer selection procedure.

III. KNOWLEDGE BASE MODEL FOR DEVICE CONNECTIVITY MANAGEMENT

We use predicates to express the facts, to show the exchange of messages between the client and server, and to describe the device states as seen by the agent.

Excellent(b, x) becomes true when the received signal strength of bearer b by the device x is higher than the specified value of TrapInactivePower. Good(b, x) becomes true when the received signal strength of bearer b by the device x is between the specified values of TrapActivePower and TrapInactivePower. If the device senses signal strength of b below the specified value of TrapActivePower then the Bad(b, x) gets true. In case the device x uses bearer b then Used(b, x) is true. InArea(a, x) is true when the device x is in the area a. Predicates PreferredIn(b, a) and PreferredOut(b, a) are true when bearer b is preferred bearer in area a and out of area a respectively. The express the fact that bearer b is available for device x the Available(b, x) is used. When there are no available bearers for x except the used one then AvailableEmpty(x) is true. BadPreferred(x) is true the received signal strength of preferred bearer by the device x is bad. Best(b, x) is true if the received signal strength of b is the maximal one for device x. PowerTrapActive(x, b) gets true when the power trap goes active and the signal strength of used bearer b by device x becomes bad. PowerTrapInactive(x, b) gets true when the power trap goes inactive and the signal strength of used bearer b by device x becomes excellent.

The behavior of the Connectivity Management Agent is described by temporal logic. We use a minimal set of standard notations G for always, U for until, and N for next.

The agent considers the following statement when explores the current device state, formulates the problem, searches the solution and performs actions.

The device x is unregistered until a registration request is received:

G(Unregistered(x)→⊤U regreq(x)) (1) After successful device registration, the server configures

geo trap and power trap. If the device x is unregistered and a registration request is

received then a registration response is sent, and a request for geo trap configuration is sent, and the state becomes WaitGeoAck:

G(Unregistered(x)∧regreq(x)→regres(x)∧ ¬BadPreferred(x)∧configGeoTrapres(x)∧NWaitGeoAck(x)) (2)

Page 7: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

The device x is in WaitGeoAck state until the server

receives a response of geo trap configuration: G(WaitGeoAck(x)→⊤U configGeoTrapres(x)) (3) If the state is WaitGeoAck and a response of geo trap

configuration is received then a request for configuration of power trap is sent and the state becomes WaitPowerAck: G(WaitGeoAck(x)∧configGeoTrapres(x)→

configPowerTrapreq(x)∧ NWaitPowerAck(x)) (4) The device x is in WaitPowerAck state until the server

receives a response of power trap configuration: G (WaitPowerAck(x)→⊤U configPowerTrapres(x)) (5) After successful configuration of geo and power traps the

server requests the device location and the device connectivity parameters. G(WaitPowerAck(x)∧configPowerTrapres(x)→

getLocationreq(x)∧NWaitLocation(x)) (6) The device x is in WaitLocation state until a location

response is received. G(WaitLocation(x)→⊤U getLocationres(x)) (7)

The location response will allow the server to determine whether the device x is in are a: G(WaitLocation(x)∧getLocationres(x)→

connParametersreq(x)∧N WaitConnectivity(x)) (8) The device x is in WaitConnectivity state until a

connectivity parameters response is received. The connectivity parameters response will contain the signal strength of used bearer b by device x and available bearers for device x. G(WaitConnectivity(x)→⊤UconnParametersres(x))(9)

Equations from (10) to (13) refer to bearer selection procedure when the device x is in area a.

When the used bearer of x is b, and b is the preferred bearer in area a, and the signal strength of b is excellent or good, then the state becomes Operational: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a, x)∧PreferredIn(b, a)∧Used(b, x) ∧ (Excellent(b, x)∨Good(b, x))→ NOperational(x))(10)

When the used bearer b of x is the preferred one, and the signal strength of b is bad, and c is available bearer for device x and c is the best bearer then a request to select bearer c is sent, and the state becomes WaitBearerAck: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a,x)∧PreferredIn(b,a)∧Used(b,x)∧Bad(b,x)∧ Available(c, x)∧Best(c, a) → selectreq(x,c)∧

BadPreferred(x)∧NWaitBearerAck(x)) (11) The bearer c selection procedure takes place when c is

available and preferred bearer, and the received signal strength of c by device x is not bad: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a,x)∧Used(b,x)∧¬PreferredIn(b,a)∧ Available(c,x)∧PreferredIn(c, a)∧¬BadPreferred(x) →selectreq(x, c)∧NWaitBearerAck(x)) (12)

When the used bearer of x is not the preferred one, and c is available and preferred bearer in area a, and the received signal strength of c by device x is bad, and d is the best

available bearer then the server initiates bearer d selection procedure: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a, x)∧ Used(b,x)∧¬PreferredIn(b,a)∧Available(c,x) ∧ PreferredIn(c,a)∧BadPreferred(x)∧Best(d,a)∧ Available(d,x) → selectreq(x,d)∧

NWaitBearerAck(x)) (13) Equations from (14) to (17) refer to bearer selection

procedure when the device x is out of area a. When the used bearer b of x is the preferred one, and the

signal strength of b is excellent or good, then the state becomes Operational: G(WaitConnectivity(x)∧connParametersres(x)∧ ¬InArea(a, x)∧PreferredOut(b, a) ∧Used(b, x)∧ (Excellent(b, x)∨Good(b, x)) →NOperational(x)) (14)

When the used bearer b of x is the preferred one, and the signal strength of b is bad, and c is the best available bearer then a bearer c selection procedure take place:

G (WaitConnectivity(x)∧connParametersres(x)∧ ¬InArea(a,x)∧PreferredOut(b,a)∧Used(b,x)∧ Bad(b,x)∧ Available(c,x)∧Best(c,a) → selectreq(x,c)∧

BadPreferred(x)∧NWaitBearerAck(x)) (15) In case the used bearer b of x is not the preferred one, and c

is available preferred bearer, and the received signal strength of c by device x is not bad, then the server request selection of bearer c: G(WaitConnectivity(x)∧connParametersres(x)∧ ¬InArea(a, x)∧Used(b,x)∧¬PreferredOut(b,a)∧ Available(c, x)∧PreferredIn(c, a)∧¬BadPreferred(x) →selectreq(x,c)∧ NWaitBearerAck(x)) (16)

When the signal strength for the preferred bearer c is bad and d is the best available bearer then the server request selection of bearer d: G(WaitConnectivity(x)∧connParametersres(x) ∧ ¬InArea(a,x)∧Used(b,x)∧¬PreferredOut(b,a) ∧ Available(c,x)∧ PreferredIn(c, a)∧ BadPreferred(x)∧Best(d,a)∧ Available(d,x) →

selectreq(x, d)∧NWaitBearerAck(x)) (17) When there are no available bearers for device x, and the

received signal strength of b by device x is good the state becomes Operational: G(WaitConnectivity(x)∧connParametersres(x)∧ Used(b,x)∧(Excellent(b, x)∨Good(b, x))∧

AvailableEmpty(x)→ N Operational(x)) (18) The server considers the device x unregistered when the

received signal strength of the used bearer b is bad and there are no available bearers: G(WaitConnectivity(x)∧connParametersres(x)∧ Used(b,x)∧Bad(b,x)∧AvailableEmpty(x)→

NUnregistered(x)) (19) The device x is in WaitBearerAck state until the server

receives a response of bearer selection procedure: G(WaitBearerAck(x)→⊤U selectBearerreq(x, b))(20)

When a beater selection response is received, the server waits for device re-registration:

Page 8: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

G(WaitBearerAck(x)∧selectBearersres(x)→ NWaitReregistration(x)) (21) The device x is in WaitReregistration state until the server

receives a registration request: G(WaitReregistration(x)→⊤Uregreq(x)) (22)

Upon successful device re-registration the server request device location: G(WaitReregistration(x)∧regreq(x)→regres(x)∧ ¬BadPreferred(x)∧getLocationreq(x)∧

NWaitLocation(x)) (23) The device x is in Operational state until the server receives

a notification about signal strength change of used bearer by x or a notification about change of x location: G(Operational(x)→

⊤U (notifyPowerreq(x)∨notifyGeoreq(x))) (24) In Operational state, when a notification about location

change of device x is received, the server sends a response of geo trap notification and requests device connectivity parameters: G(Operational(x)∧notifyGeoreq(x)→notifyGeores(x)∧

connParametersreq(x)∧NWaitConnectivity(x)) (25) When the power trap becomes inactive in Operational state,

the server sends a response of power trap notification and the state remains Operational: G(Operational(x)∧notifyPowerreq(x,b)∧PowerTrapInactive(x)

→ notifyPowerres(x,b)∧ NOperational(x)) (26) Activation of power trap in Operational state means that the

signal strength becomes bad and the server sets the margin timer: G(Operational(x)∧notifyPowerreq(x,b)∧ PowerTrapActive(x)→notifyPowerres(x,b)∧

setTmargin(x)∧NWaitMargin(x)) (27) The device x is in WaitMargin state until the server receives

a notification about signal strength change of used bearer by x or a notification about change of x location: G(WaitMargin(x)→⊤U (notifyPowerreq(x,b)∨

notifyGeoreq(x)∨Tmargin(x))) (28) Notification that the power trap is inactive in WaitMargin

state means that the signal strength becomes excellent and the server and resets the margin timer: G(WaitMargin(x)∧notifyPowerreq(x,b)∧ PowerTrapInactive (x)→notifyPowerres(x,b)∧

resetTmargin(x)∧N Operational(x)) (29) In WaitMargin, when the margin timer expires, the server

sends requests device connectivity parameters: G(WaitMargin(x)∧Tmargin(x) →

connParametersreq(x)∧N WaitConnectivity(x)) (30) The device may change its location while it is in

WaitMargin state: G(WaitMargin(x)∧notifyGeoreq(x)→ notifyGeores(x)∧N WaitMargin (x)) (31)

When the device is unregistered due to connectivity problems, it may wait for some time and try to register again.

For brevity sake the behavioral model of the Connectivity Management Agent is given without parts like re-registration

which is caused by registration timer expiry, APN activation due to change of network bearer etc.

IV. CONCLUSION

Embedding autonomic features in M2M systems reduces operational costs. Following the goal of ensuring a reliable and efficient M2M network, autonomous agents that perceive from the M2M ecosystem and act upon it can contribute to self-optimization.

We present an algorithm for choosing the best bearer and model the behavior of Connectivity Management Agent which selects radio technologies in wireless environment according to current radio conditions. The agent monitors the connectivity parameters on M2M devices and based on the device location and policies defined by the device operator, selects the best network bearer to be used by the device. The model is formally described by temporal logic. Our future work will include more details related to APN configuration, device rebooting and firmware update.

REFERENCES

[1] P. Watson, K. C. Gupta, “EM-ANN Models for Microstrip Vias and Interconnects”, IEEE Trans., Microwave Theory Tech., vol. 44, no. 12, pp. 2395-2503, 1996.

C. Pereira, A. Aguiar, “Towards Efficient Mobile M2M Communications: Survey and Open Challenges,” Sensors 2014, no. 14, 19582-19608; doi:10.3390/s141019582, pp.19582-19608.

[2] J. Sachs, N. Beijar, P. Elmdahl, J. Melen, F. Militano, P. Salmela, “Capillary networks – a smart way to get things connected,” Ericsson Review, 2014, no. 8, pp. 2-8.

[3] D. Kyriazisa, T. Varvarigoua, “Smart, autonomous and reliable Internet of Things,” International Workshop on Communications and Sensor Networks (ComSense’2013), International Workshop on Communications and Sensor Networks, ComSense’2013, Procedia Computer Science, 2013, pp. 442 – 448.

[4] S. Vassaki, G. Pitsiladis, C. Kourogiorgas, M. Poulakis, A. Panagopoulos, G. Gardikis, S. Costicoglou, “Satellite-based sensor networks: M2M sensor communications and connectivity analysis”, International Conference on Telecommunications and Multimedia (TEMU), Greece, 2014, pp.132–137.

[5] K. Misura, M. Zagar, “Internet of things cloud mediator platform,” International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2014, pp.1052-1056

[6] M. Ruta, F. Scioscia, G. Loseto, E. Di Sciascio, “Semantic-Based Resource Discovery and Orchestration in Home and Building Automation: A Multi-Agent Approach,” IEEE Transactions on Industrial Informatics, vol. 10, no. 1, 2014, pp.730-741.

[7] S. Frey, A. Diaconescu, D. Menga1, I. Demeure, “Towards a generic architecture and methodology for multi-goal, highly-distributed and dynamic autonomic systems,” International Conference on Autonomic Computing (ICAC), 2013, pp.201-212.

[8] G. Klas, F. Rodermund, Z. Shelby, A. Akhouri, J. Holler, “Lightweight M2M”: Enabling Device Management and Applications for the Internet of Things,” white paper, 2014.

[9] Open Mobile Alliance, Enabler Test Specification for Lightweight M2M, 2015, OMA-ETS-LightweightM2M-V1_0-20150203-C.

[10] Open Mobile Alliance, Diagnostics and Monitoring Trap Events Specifications,2013,OMA-TS-DiagMonTrapEvents-V1_2-20131008-A

Page 9: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

Integrated HPC Data-log Monitoring System Kostadin Mishev1, Sonja Filiposka2, and Anastas Mishev3

Abstract – Monitoring HPC systems is crucial for the increase of their efficient usage. Integrated monitoring, based on data from various monitoring sources gives a broader picture and enables in depth understanding of the systems, reducing their power consumption and developing of new, highly effective HPC software.

Keywords – HPC, monitoring, efficient usage.

I. INTRODUCTION

High Performance Computers (HPC) represent one of the the main building blocks of the todays e-Infrastructures [1]. Together with cloud-based solutions and efficient distributed large scale storage on top of ultrafast agile network, they are a crucial element that provides the processing power needed to tackle with big data problems.

However, achieving their optimal usage comes with a whole plethora of new problems and challenges. With the most important resource being processing power achieved with a huge number of cores (CPUs and accelerator cores like GPGPUs and Xeon Phy’s), the goal of maximum performance needs to be reached under a complex set of constraints like efficient core usage, minimum inter process communication, but also minimized power consumption. Thus, the effective usage of these computing giants needs thorough monitoring that will reveal the usage of the available resources and the way they respond to different loads and tasks [2].

Most of the current monitoring solutions are vendor dependant proprietary solutions like IBM Platform HPC [3], HP Insight Cluster Management Utility [4], Fujitsu HPC Cluster Suite [5]. They provide various types of monitoring of HPC systems, mostly offering chassis and operating system (OS) level analysis and visualization tools.

Notable open source monitoring solutions include Ganglia [6], Nagios [7], and OVIS [8]. These tools are usually based on probes running on the hosts themselves and different ways of collecting and representing the collected data.

Important questions that arise regarding the HPC monitoring [9] include the understanding of the HPC monitoring process, its evolution, technologies and vendor

lock-ins vs neutrality. Vendor specific proprietary tools usually offer higher levels of details, while the open source solutions give more flexibility.

There are several perspectives of the HPC monitoring that should be taken into account when implementing a monitoring solution: OS level monitoring, chassis level monitoring, power consumption monitoring etc. The integration of different monitoring data sources gives a more complete and wider perspective [10]. Using integrated data, such as host or chassis level power consumption combined with the CPU and memory usage can help in developing power aware algorithms, schedulers etc. One of the main challenges when integrating monitored data from different sources is the time based association of the data that is gathered using different sampling rates, i.e. monitoring data with different resolution.

HPC monitoring systems can be implemented as real-time monitors or log analysis tools [11]. Although real time monitoring provides valuable data for the current state of the HPC cluster, monitoring based on log analysis offers more in-depth view of the overall system parameters and can lead to important conclusions regarding the correlation of the values of measured parameters obtained from different sources and levels.

In this paper we present a HPC data-log monitoring system acting as a collection server for monitoring data that stems from different sources. Upon collection, the system adapts the data into one common format, aligning the different sampling resolutions of the available monitored data. The summarized output of the system can be used for various purposes such as performance analysis, power consumption examination etc.

The rest of the paper is organized as follows. Part II describes the sources of data aggregated by the proposed system. Part III explains the system architecture, while Part IV discusses the possible applications of the system. Part V concludes the paper and points toward the future work.

II. MONITORING SOURCES

HPC monitoring data can be integrated from various sources that will provided information concerning different aspects of the system like node level monitoring, enclosures parameters, and out-of-band system management interfaces.

In order to obtain monitoring data from the OS perspective, a cluster management software (CMS) [12] can be used. Upon deployment, each computing node runs an agent of the cluster management utility that sends data to the appointed management node. Usually, the utility solution provides a tool for real time monitoring and visualization of the collected data. This data includes: CPU load and frequency, memory usage, OS version, disk space usage, etc. In order to obtain logged data for a specific time period, a command line tool can be used. This tool enables the user to select a subset of nodes and the parameters that will be exported to a file with a flat structure (timestamp, nodeID, parameter, value). This

1Kostadin Mishev is with the Faculty of Computer Science and Engineering at Ss. Cyril and Methodius University in Skopje, Rudjer Boshkovikj 16, Skopje 1000, Macedonia, E-mail: [email protected].

2Sonja Filiposka is with the Faculty of Computer Science and Engineering at Ss. Cyril and Methodius University in Skopje, Rudjer Boshkovikj 16, Skopje 1000, Macedonia, E-mail: [email protected].

3Anastas Mishev is with the Faculty of Computer Science and Engineering at Ss. Cyril and Methodius University in Skopje, Rudjer Boshkovikj 16, Skopje 1000, Macedonia, E-mail: [email protected].

Page 10: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

dump can then be combined and aligned with the other collected datasets.

Another common monitoring data source is the so-called Light-out management system (LOM) [13]. LOM uses a dedicated management channel to monitor and remotely manage nodes regardless of whether they are powered on, or if an operating system is installed or functional, i.e. compared to the cluster management utility, it provides an external monitoring view of the nodes and their enclosures. The data acquired from this system includes chassis information, power usage and distribution by chassis elements, aggregated thermal monitoring data, etc.

Although the LOM solutions are specialized implementations of the Intelligent Platform Management Interface (IPMI) [14], the direct use of IPMI enables further enrichment of the gathered data. IPMI is in fact a specification for interfaces used for out-of-band management of computer systems and monitoring of their operation. Using IPMI one can gather more detailed data including current power consumption, various temperature sensor readings and fan speed on node level, compared to the LOM’s chassis level. Unlike CMUs that logs the monitoring data autonomously, using IPMI the data must be manually pulled in real-time with a given resolution. This can be achieved using the ipmitool command.

III. SYSTEM OVERVIEW

In order to obtain a holistic, yet, comprehensive, overview of the monitored system, the data gathered from the three available monitoring sources described in the previous section must be composed in a single collection. For this reasons, we propose an integrated data-logging monitoring system that will act as a collection server for the monitoring sources and thus provide a single point of reference when monitoring the usage of the HPC resources and related components.

In this section we describe the proposed system architecture and its implementation for a given HPC.

A. System architecture

Data gathered from the sources described above, are merged and saved into a database as a raw data. The captured data series are organized in reservations enabling the start and the end of data capturing. The data captured by the LOM tool is the basis for establishing the time flow and data resolution. On top of this data, the captured measurements from the other two sources are added. All data imported in the monitoring software is automatically merged and aligned using the provided timestamps.

The complete raw data is organized in different reservations characterized with reservation start and end time. Inside each reservation, the raw data that belongs to the reservation is aligned according to the LOM’s data resolution. Each reservation can be visualized using a chart panel, or it can downloaded as a set of flat files for external evaluation.

The deployed example system for integrated HPC monitoring, given on Fig. 1, is implemented using Java Spring 4.0 framework using MySQL database for data logging.

Fig. 1: System architecture

B. Use-case scenario

The described system is used to monitor a Hewlett-Packard HPC system located at the Faculty of Computer Science and Engineering in Skopje. The system is based on HP Cluster Platform 7000 enclosures with 42 blades BL2x220c G7 with dual motherboard and dual Intel Xeon L5640 @ 2.26Ghz (total 1008 cores). The blades are grouped in three enclosures.

Using HP’s Insight CMU [4] each blade can have its own monitoring station which measures several parameters such as temperature, CPU frequency, CPU load, memory used and process memory, which determine the current state of the blade depending of the current load handled by the appropriate blade. The data from the CMU is gathered using the cmu_monitoring_dump CLI tool.

The Light-out management system used for monitoring data is based on the HP’s implementation of the LOM, the HP integrated Lights Out (iLO) [15]. iLO uses a custom build scripting language, based on XML, to provide detailed information about the HPC enclosure and its elements. Each iLO-based enclosure serves as an endpoint that returns XML files presenting the values of the sensors. The enclosure which wraps a set of blades, has its own control unit. The control unit monitors the overall system health:

• the rotations per minute of cooling fans • the enclosure manager provides information about

hardware state, firmware versions and temperature of monitoring unit

• temperature of switches • power consumption and power output • ambient temperature

Additionally, using IPMI fine-grain monitoring data is

gathered on the node level, specifically node power consumption and node level CPU temperature.

More detailed information on the various available measurement parameters that can be obtained using the merged data log monitoring approach is given in Table I that can be found at the end of this paper.

Within the developed solution (available at [16]), each monitoring session is presented as a reservation. In order to

Page 11: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

conserve storage, the system is not running all the time, but is acting upon scheduled user created reservations. To enable the log during specified time period, the user must create a new reservation and specify the time interval of the active session together with the enclosures that are to be monitored. Upon creating the new reservation, using the main page, the user can monitor the current status of the reservation presented via a green slider (see Fig. 2).

Fig. 2: Monitoring reservations

Afterwards, the user can import the dump files obtained from the other sources by navigating to the Edit section of the reservation. This page assists the user to execute the appropriate commands on the native interfaces to obtain the right dump file (see Fig. 3). The file should be uploaded by using the file upload option on this page. The system calls background data merge services which matches the appropriate data parameters from different sources. The product of such merge, can be observed by navigating to the Visualize section by clicking the View button.

Fig. 3: Import of the data from other sources

On the navigation menu, the user chooses the parameters that he will observe. The result is a chart series which visualize the parameters changes over time (see Fig. 4). Also, there exists an option for downloading a zip file of a set of flat files for all parameters by reservation for additional processing.

Fig. 4 Visualization of the data

IV. APPLICATIONS

The proposed system offers a wide spectre of applications. Analysis and visualization of the execution of specific applications can help the developers optimize their solutions toward better resource utilization.

If we take power efficiency as an example, the collected data can be used for investigating power aware algorithms or schedulers, providing optimal power consumption.

Thermal related data (temperature sensors measurements, fan rotation speeds) can help avoid hot spots in the chassis by varying the scheduling and the distribution of the processes by nodes.

Analysis of the data from the networking elements can help develop intelligent parallel algorithms that will optimize interposes communication.

V. CONCLUSION

In this paper we presented an integrated monitoring solution for HPC systems. It is based on data collections from various sources including server management interfaces and OS level probes. The integrated data can be visualized or exported for further in-depth analysis. The acquired and integrated datasets can be used for better system understanding, development of novel HPC schedulers, increased resource usage under power restrictions, etc.

Future versions of the system will be aimed towards enabling finer resolution of the data sampling, real time import and alignment and wider integration and scalability.

Page 12: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

ACKNOWLEDGEMENT

This work is supported by the project Design and analysis of green ICT systems, financed by the Faculty of computer science and engineering, UKIM.

REFERENCES

[1] N. Mustafee, and S. JE Taylor. High-performance simulation and simulation methodologies. 2013.

[2] J.C Browne, R.L. DeLeon, A.K. Patra, W.L. Barth, J. Hammond, M.D. Jones, T.R. Furlani, B.I. Schneider, S.M. Gallo, A. Ghadersohi, and R.J. Gentner. Comprehensive, open-source resource usage measurement and analysis for HPC systems. Concurrency and Computation: Practice and Experience, 26(13), pp.2191-2209, 2014.

[3] IBM Platform HPC, http://www-03.ibm.com/systems/platformcomputing/products/hpc/, visited March 2016.

[4] HP Insight Cluster Management Utility, http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=3296361, visited March 2016.

[5] Fujitsu Cluster Suite, http://www.fujitsu.com/fts/microsites/hpc/products-services/index.html, visited March 2016.

[6] Ganglia Monitoring System, http://ganglia.info, visited March 2016

[7] Nagios, https://www.nagios.org, visited March 2016. [8] J. M. Brandt, A. C. Gentile, D. J. Hale and P. P. Pebay, "OVIS:

a tool for intelligent, real-time monitoring of computational clusters," Parallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International, Rhodes Island, 2006.

[9] W. Allcock, E. Felix, M. Lowe, R. Rheinheimer, and J. Fullop. Challenges of HPC monitoring. In State of the Practice Reports (SC '11). ACM, New York, NY, USA, 2011.

[10] S. Bohm, C. Engelmann and S. L. Scott, "Aggregation of Real-Time System Monitoring Data for Analyzing Large-Scale Parallel and Distributed Computing Environments," High Performance Computing and Communications (HPCC), 2010 12th IEEE International Conference on, Melbourne, VIC, pp. 72-78, 2010.

[11] C. L. Moore, et al. Monitoring High Performance Computing Systems for the End User. Cluster Computing (CLUSTER), 2015 IEEE International Conference on. IEEE, 2015.

[12] N. Bonvin, S. Vaudenay, and P. Junod. Cluster Management Software. No. LSIR-STUDENT-2009-001. 2003.

[13] H. Bojinov, E. Bursztein, E. Lovett, D. Boneh. Embedded Management Interfaces: Emerging Massive Insecurity. Black Hat USA 2009.

[14] IPMI – Intelligent Platform Management Interface, http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html, visited March 2016.

[15] HPE Integrated Lights Out (iLo), http://www8.hp.com/us/en/products/servers/ilo/index.html, visited March 2016.

[16] Integrated HPC monitoring, http://hpcm.b1.finki.ukim.mk/.

TABLE I SELECTED MEASURED PARAMETERS BY SOURCE

Parameter Applies to CMU iLO IPMI

Temperature Node X CPU frequency Node X

CPU load Node X Memory used Node X

Process memory Node X Current fan RPM Chassis X

Output power Chassis X Input power Chassis X

Power supplies Chassis X Ambient temp Chassis X Power meter Node X CPU temp Node X

Inlet ambient temp Node X DIMM temp Node X

Memory zone temp Node X Chipset temp Node X

NIC temp Node X System exhaust temp Node X

Virtual fan Node X Enclosure status Node X Memory status Node X

Health LED Node X Per switch temp Chassis X Manager temp Chassis X

Power on switch Chassis X Power off switch Chassis X

Page 13: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

E-content Development and Task Solution Using the

Content Management System of Online-CADCOM Galia Marinova

1 and Ognyan Chikov

2

Abstract – The paper presents different types of e-content in

Online-CADCOM and the methodology steps for its

development, using Content Management System. The

methodology is illustrated by adding e-content for a new online

tool WEBENCH Clock Architect (TI). Later a design and

verification task is solved using the new tool from the CMS and

the simulator ORCAD Design Suit for verification.

Keywords – E-content, Content Management System, E-

content development, Design and verification task solution, PLL

loop filter design.

I. INTRODUCTION

Online-CADCOM [1,2] content is dynamically generated

from the Content Management System (CMS) [4], once the

content is successfully developed and uploaded through the

user interface. The platform has unique and major capabilities

which turn Online-CADCOM in powerful web platform that

has the following features through the CMS platform:

Automated templates – new content is automatically

applied to the existing templates and views, as also all

content can be changed from a central place.

Access control – user groups allow Online-CADCOM to

be controlled on different hierarchical levels and they

determine how registered users interact with the CMS

system

Scalable expansion of content – the CMS platform offers

ability to expand content in future work as adding more

files, new categories and etc.

Easily editable content – the content is separated from the

visual presentation of the web platform and it is very easy

to edit and manipulate by non-technical users, which is the

main focus and idea of using CMS approach.

Workflow – technique used for uploading a content in the

platform which gives abilities for workflow management

and multiuser parallel tasks.

Collaboration – the content of the platform is retrieved and

uploaded by one or many authorized users. Changes can

be made from all authorized users, and this can be

considered as advanced form of collaboration that allows

multiple users to make changes of a content material at the

same time, from different geographical locations.

Delegation – user levels of access provide limited access

for different user groups over specific sections of platform,

which divide into small part the responsibility for the

management.

Content Virtualization – CMS platform allows each user to

work with a virtual copy of the whole web site, documents

and resources included. This feature enables changes to

multiple resources to be viewed prior to submission.

Multilingual – with the developing of the CMS, the

multilingual functionality is embedded. This gives the

ability to display the content in different languages, not

only the native.

The paper is organized as follows: Types of e-content and

methodology steps for e-content development, using the CMS

menus are described firstly. The process is illustrated for the

integration of a new tool WEBENCH Clock Architect

(WBCA) [7]. Then task solution using the platform is

illustrated through an example of design and verification of

PLL (Phase-locked loop) loop filter using WBCA tool and

ORCAD/PSpice simulator.

II. E-CONTENT AND METHODOLOGY STEPS FOR

ITS DEVELOPMENT IN ONLINE-CADCOM

A. E-content in Online-CADCOM

E-content development using CMS platform is an intuitive

process, thanks to the proper scalability of the platform as

described in [3]. The content of Online-CADCOM would not

be limited only to online tools. The platform is built by

different types of e-content with different specifications and

functions. In CMS, the approach used to develop and create e-

content is using methods for CRUD (Create, Read, Update,

Delete). These main methods are implemented in buttons that

are visible in the bottom of each section of platform – “Add”,

“Show”, “Edit” and “Delete”. Moreover, the content is highly

protected using a login screen for the platform and also

different user-type levels as described in [3] with different

levels of access and platform rights. Development of e-content

can be conditionally divided into:

Categories,

Tools,

Portals,

Standards,

Knowledge Base,

Estimation tools,

Prototype tools,

Optimization tools.

1Galia Marinova is with the Faculty of Telecommunications at

Technical University of Sofia, 8 Kl. Ohridski Blvd, Sofia 1000,

Bulgaria, E-mail: [email protected]. 2Ognyan Chikov is with the Faculty of Telecommunications at

Technical University of Sofia, 8 Kl. Ohridski Blvd, Sofia 1000,

Bulgaria. E-mail: [email protected].

Page 14: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

Categories in the platform are related with Panel 1 and 2,

which cover the Daniel-Gajsky Y model used in Online-

CADCOM and represent the content related with the

categories of this model. These categories can contain both

subcategories and online tools with individual tool passports.

Adding a category does not affect tools and vice versa. This

means that the two sections are separate and independent and

the content is not connected, but separated in the categories.

In CMS, the tools section gives the opportunity to develop

content related with different online tools. A tool passport is

used as described in [3] for identification of the tool before

integration in the platform. Here, different tools are added,

edited and deleted. During the process of development the

content provides an option to choose the related category or

subcategory for the tool which is added.

The section with portals gives the possibility of adding

different type of engineering portals that can contain useful

and important information about all users that will use Online-

CADCOM. The information is not limited to text, but also to

images and video files, which make this section an extremely

useful for quick and reliable information and future links to

useful products that are out of Online-CADCOM scope.

”Standards” is another section in the platform that provide

the users with information about different standards in

telecommunications and system design. Information here is

not limited to name, date and title of the standard but a

standard can also be downloaded from the platform using the

button “Download”. The platform is developed in a way that

content can be up to one document per title and the document

formats are limited to *.doc, *.docx and *.pdf. Limitation is

needed for storage optimization and also virus, worms and

adware protection of the E-content.

The Knowledge Base contains a large number of materials

in different categories. Visitors of Online-CADCOM can view

and download knowledge materials such as how-to

documents, videos and another knowledge material.

“Estimation tool” section of CMS allows the administrators

to upload estimation tools in the platform as the logic is the

same as the tools in the Y model of Panel 1 and Panel 2, but

without subcategories. This limitation is done because of the

used method of showing items from this menu – using

dynamic number of pages according to the number of

Estimation tools. Here the same approach for tools

classification, using tool passports is covered.

The section ”Outcome to prototype” is developed for e-

content related with tools that can be used for prototype

engineering work.

Optimization menu is developed for tools that are used for

optimization task and solutions.

The CMS is developed to facilitate the work of Online-

CADCOM administrators and to make content development

and upload easy and fast task, without need of programming

skills. The scope of using the platform is tasks solving related

with the e-content in Online-CADCOM. Some of the options

of CMS are:

New Category/Subcategory creation through CMS;

Adding a new tool with passport in a specific Category;

Developing/Adding e-content in the Knowledge Base.

B. Methodology steps for e-content development in Online-

CADCOM

The main methodology steps for e-content development in

Online-CADCOM, using the CMS are: Adding a new

category/subcategory; Adding a new tool in a category;

Passport filling for a new tool; Development and adding e-

content in the Knowledge Base to help task solution with a set

of tools.

These steps are considered in details and they are

illustrated through the example of adding the new Online tool

WBCA, which is a module in the Online Platform

WEBENCH Design Center of TI [8], in a new subcategory

”PLLs”. The new tool permits design, simulation and

optimization of clock tree solutions for given input and output

frequencies. The main circuit used is the PLL. Details about

PLL design and important building blocks as Voltage-

controlled oscillator (VCO) and PLL loop filter can be found

in [6]. More about datasheet specification reading of a PLL

device is presented in [5].

Adding new subcategory

As described in [3], categories in Online-CADCOM are

related with Panel 1 and Panel 2 of the front page. More

categories or subcategories can be added through the Content

Management System and they automatically stand behind the

main categories that build up the Panel 1 and Panel 2. This

approach is used because of Daniel-Gajsky Y model and tools

classification according to it. Category creation is easy and

can be made from the platform menu – “Categories”. After

opening this menu, the main screen shows all the current

categories that are created in the system. These categories

correspond to the names of the buttons of Panel 1 and Panel 2.

As described above, a category can contain a subcategory. For

creation of a new category, the button “Add” must be pressed.

Categories can be deleted using button “Delete”.

For the needs of the new online tool, a new subcategory

“PLLs“ has to be created in the existing Category “RF and

Microwave“.

Adding a new online tool

Tools can be added to the platform using the section –

Tools. First when this button is clicked, a window with all

tools is shown on the screen. A new tool can be added using

the “Add” button. The process is the same as for adding a new

category/subcategory, but here the user must fulfill the form

that represents the tool passport with all information related to

the specific tool. The development of the e-content for the

online tool content must be consistent with the categories. If

there is no category, no tools can be added. Also when a tool

is added, a selection form with the category must be chosen,

otherwise the platform generates an error. Tools can be easily

removed using the “Delete” button.

Figure 1 illustrates the creation of the e-content for the new

online tool WBCA. The creation of the content for the new

tool begins with the name of the tool and an image

symbolizing the tool. The image chosen to symbolize the

WBCA is a clock tree block diagram. The web address of the

new online tools is added in order to perform “Launch”

Page 15: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

function for accessing and running the new tool. Figure 2

illustrates the vision of the new tool on Panel 1, subcategory

“PLLs“ of the Category “RF and Microwave“.

Passport filling for a new tool

Figure 3 illustrates the parameter filling in the passport of the

tool WBCA and Figure 4 shows the e-content of the passport

filled, visualized by Online-CADCOM. The new tool is a

module in the online platform WEBENCH Design Center of

TI. It's acting at the transistor level from the Daniel Gajsky Y-

model. The application area is defined as PLL design and

simulation, the functions are selected from a predefined set,

then input/output connections with other existing tools are

enumerated and ORCAD/PSpice is pointed as a verification

tool. Some quantitative and qualitative features are added in

the last 2 fields of the passport. The input/output connections

show possibilities for combining the tool WBCA with other

tools for solving complex design tasks.

Developing and adding e-content in the Knowledge Base

The Knowledge Base contains different type of materials

and files, which help engineers to solve complicated tasks.

Knowledge Base materials can be of any kind of files –

documents, pictures and etc. Uploading a Knowledge Base

material is an automated task that requires only to fulfil the

forms of Knowledge Base section and to point a file to be

uploaded. A new knowledge material can be created with the

button “Add”. Then a window with forms for creation of the

material is shown. After completion of filling forms, with the

button “Save”, the new knowledge material is added to the

database and is ready to be visualized in Online-CADCOM.

Instructions for how to combine tools in Online-CADCOM, in

order to solve complex design and verification tasks, are part

of the e-content in the Knowledge base. A new instruction for

verification of the PLL loop filter designed with WBCA,

using the simulator ORCAD/PSPICE is uploaded to the

Knowledge Base.

Fig.1. Adding New tool WEBENCH Clock Architect in the

category “RF and Microwave”, subcategory “PLLs”

Fig.2. Visualization of the tool WEBENCH Clock Architect and its

image on Panel 1

Fig.3. Filling e-content for the passport of WEBENCH Clock

Architect

Fig.4. Visualization of the passport filled in Online-CADCOM

Page 16: Formal Verification of Models for M2M Device Registrationicestconf.org/wp-content/uploads/icest_2016/05_CSIT_O_4_16.pdf · provided by OMA LWM2M [5], [6]. Lightweight M2M is a protocol

III. DESIGN TASK SOLUTION IN ONLINE-CADCOM

Once the WBCA tool is integrated in Online-CADCOM, it is

used for design verification combining the online tool with

Orcad Design Suit 16.6 program [9] and PSpice simulator,

following the instructions given in the Knowledge Base.

Fig.5. Loop filter design circuit, parameters and simulation results in

WEBENCH Clock Architect

Fig.6. Circuit of the loop filter in ORCAD/Capture 16.6

Fig.7. Gain and Phase simulation curves of the loop filter from Fig.6

simulated in ORCAD/PSpice 16.6

First a clock tree with specification for an input frequency

of 25 MHz and 3 output frequencies of 24 MHz, 27 MHz, 24

MHz is designed. One of the 10 proposed solutions is

considered. Then the LoopFilter>Advanced options are

selected. The circuit selected is Active A (low slew rate) 3rd

Order. The filter circuit and the curves simulated in WBCA

are presented on Figure 5. The parameters of the loop filter

obtained by WBCA are: Bandwidth – 414 kHz and Phase

Margin - 83.8°.

Then the circuit of the loop filter is drawn in ORCAD

Capture as shown on Figure 6. The circuit is with negative

feedback which follows the theory in [6] and gives meaningful

simulation results. The filter from Figure 6 is simulated in

frequency area (AC) and the curves for the Gain and the Phase

are presented on Figure 7. The loop filter parameters

determined from the simulated curves are Bandwidth – 428

kHz and Phase Margin - 92.5°. The curves from Fig.7 are

similar in form as the curves of Forward loop gain and Phase

Margin from Fig.5, but there are some differences in the

values of the parameters obtained. It would be good to know

the motivation for using the positive feedback circuit in

WBCA on the other hand, it's worth to verify the designs with

ORCAD/PSpice and to search the most realistic solution, as

basis for further optimization of the clock tree design.

IV. CONCLUSION

Using the CMS for e-content development and for task

solution is a job that does not require special programming

skills. E-content can be easily created with help of few

sections and buttons. The platform is intuitive and easy to

operate with. Content can be changed dynamically and

anytime. The ease-of use is illustrated by adding e-content for

the online tool WBCA to Online CADCOM. A process of

adding e-content for hundreds of online tools is foreseen in

near future. The results from the design and verification task

show that such a study is needed in order to compare results

and to fix better parameters obtained and to optimize designs.

ACKNOWLEDGEMENT

This research is partly supported by Project №152PD0039-

07 in Technical University – Sofia.

REFERENCES

[1] G. Marinova, V. Guliashki, O. Chikov, “Concept of Online

Assisted Platform for Technologies and Management in

Communications – OPTIMEK”, ICCSIST 2014, 7-9 November

2014, Durres, Albania, 2014, pp.55-62

[2] O. Chikov, G. Marinova, MVC Framework Approach in the

Online assisted platform form Computer-aided Design in

Communications – Online-CADCOM, Computer and

Communications Engineering, TUS, 2016.

[3] G. Marinova, O. Chikov, Methodology for tools integration in

the Online Assisted Platform for Computer-aided design in

communications, Proc. of papers of ICEST’2015, 24-26 June

2015, Sofia, pp.31-36, ISBN:978-619-167-182-3

[4] O. Chikov, "Software development of Content Management

System in Online-CADCOM platform", submitted to

ICEST'2016, Ohrid, Macedonia

[5] S. Damphousse, How to estimate the phase noise of a PLL with

basic datasheet specifications, Texas Instruments, March 2,

2016,https://e2e.ti.com/blogs_/b/analogwire/archive/2016/03/02

/understanding-datasheet-phase-noise-specifications-of-a-phase-

locked-loop?DCMP=lmx25x2&HQS=sva-sds-fcp-lmx25x2-

exah-null-null-eu

[6] D. Banerjee, PLL Performance Simulation and Design

Handbook - 4th Edition, 13 October 2006

[7] WEBENCH Clock Architect, TI

http://www.ti.com/lsds/ti/analog/webench/clock-architect.page

[8] WEBENCH Design Center, TI,

http://www.ti.com/lsds/ti/analog/webench/overview.page?DCMP

=sva_webench&HQS=webench-btechday

[9] Orcad Design Suit 16.6, Users’ Guide, Cadence, 2014