# A Consolidated DaaS Model for Situation-Informed Incident Management

Nan Jiang, Lai Xu, Paul De Vrieze

► To cite this version:

Nan Jiang, Lai Xu, Paul De Vrieze. A Consolidated DaaS Model for Situation-Informed Incident Management. 14th Working Conference on Virtual Enterprises, (PROVE), Sep 2013, Dresden, Germany. pp.375-384, 10.1007/978-3-642-40543-3_40. hal-01463231

HAL Id: hal-01463231

https://inria.hal.science/hal-01463231

Submitted on 9 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Consolidated DaaS Model for Situation-Informed Incident Management

Nan Jiang¹, Lai Xu¹ and Paul de Vrieze¹

¹ Software Systems Research Centre,
School of Design, Engineering and Computing,
Bournemouth University, United Kingdom
{njiang, lxu, pdvrieze}@bournemouth.ac.uk

**Abstract.** From Fukushima Daiichi nuclear disaster to the recent India blackout, industrial incidents are inevitable and once occurred, their impact on the society and economy can be catastrophic. In an end user perspective, reducing such impact relies on not only efficient service recovery but also effective public communications. To achieve the latter, it requires instant resource sharing in a collaborative network where effective data sharing, integration and management are critical. However, this is not an easy-to-achieve task in a complex system which involves a number of stakeholders. In this paper, we describe a consolidated DaaS model based on our previous work, which can be used to support effective communications in emerging situations and sudden events driven by incidents. We also provide an implementation based on a case study focusing on power incident management in the UK's national electrical system to demonstrate the usefulness of the model.

**Keywords:** Cloud computing, Situational applications, Mashup, Data as a Service (DaaS), Power grid, Incident management.

## 1 Introduction

Large industrial systems such as power grid or communication networks are becoming more and more complex so that industrial incidents are inevitable. An incident can make strong adverse impact on the society and economy when it is related to our everyday life [1]. More importantly, the economic cost is often tremendous and leads to catastrophic consequences [2] [3]. For example, apart from 3.5 percent of GDP equivalent direct losses through damages [4], the accident at Fukushima has resulted in radical community reaction due to the lack of effective communications from main stakeholders [5]. Therefore, reducing such impact relies on not only efficient service restoration but also effective public communications [26]. The latter requires ICT enabled instant resource access, sharing and collaboration in the collaborative network where effective data sharing, integration and management of complex systems are critical [27].
Following our previous study [24], this paper presents a consolidated DaaS model that can be used to realize effective incident management. The main contribution of this model is that it supports timely collaborations across all organizations in response of emerging situations and sudden events in an on-demand and cost-effective manner.

The paper is organized as follows. First, Section 2 describes the principles and rationale of the model. Section 3 provides an overview of the consolidated model. Section 4 conducts a case study focusing on the UK's national electric system and Section 5 presents the corresponding implementation considerations. Last, the conclusion is drawn in Section 6.

## 2 Principles

The principles and rationale behind of the three-tier DaaS model are web principles, service-oriented principles and autonomic computing principles.

### 2.1 Web Principles

A web-based system often emphasizes on open modularized architectures and rapidly changing technologies which make it flexible and easy to extend [6]. This also applies to Data-as-a-Service, a service model of cloud computing which allows data in various formats and from multiple sources to be provided through services on demand [10]. The goal of this model is to support effective communications from stakeholders to end users in a complex system so a prerequisite is that every partnering organization should be able to contribute effortlessly to the system despite their roles. In other words, the usage of the DaaS model must be simple, slick and unrestricted.

The model should support the collaborative process from several computing power to run a single task transparently and coherently. It also allows the transparent distribution of components over the network so that executing processes running in the middleware can be scaled across numerous physical servers that span across organizations in a cloud environment. Moreover, the integration of heterogeneous proprietary and legacy solutions should be supported through common interfaces. Additionally, interoperability on the web is usually platform- and vendor-independent which allows all providers and requesters of information to participate on a level playing field.

### 2.2 Service-Oriented Principles

Service-orientation provides a broad design paradigm that enables the separation of concerns by allowing using services as the basic building blocks of functionality [28]. It also provides a way to think about the design of a solution in terms of services, service-based development and the outcomes of the services. The DaaS model aims at providing enhanced efficiency, agility, flexibility and productivity by positioning services as the primary atomic functional elements [7]. These services are classified
based on the functionality provided within the model, which can be distinguished
between application, data, and middleware services.

* Application services, which are the top layer in the service oriented architecture, provide business logic. Moreover, they are the subject of integration and interoperation within the architecture and can provide a certain value for users.

* Data services provide on demand access to the user.

* Middleware services, such as services providing discovery and interoperation support, are used to facilitate the integration and interoperation of business services.

All these services should be designed and developed, according to a holistic approach.

## 2.3 Autonomic Computing Principles

The concept of autonomic computing was first introduced in [8] where autonomous systems were characterized as self-manageable systems. This is very important for services. Our model is supported by composing services offered by third parties. Such system does not necessarily have control on the way the component services are actually offered. Therefore, self-management capability is important for the system. It allows the system to react to the situation in which the services provide incorrect results or are unresponsive.

The characteristics of autonomous systems are being applied today in four fundamental areas of self-management to drive significant operational improvements. The four areas are related to different attributes of autonomous systems. The four capabilities are self-configuring capabilities, self-healing capabilities, self-optimizing capabilities and self-protecting capabilities.

# 3 Three-tier DaaS Model

Fig. 1 shows the three-tier DaaS model featuring *data tier*, *service tier* and *interface tier*. First, member organizations in a collaborative network can publish their enterprise data which are relevant to end customers as individual data services. These services can then be hosted in a service cloud in either linked or centralized form so that they can be discovered and accessed by all members. After that, any member can identify emerging situations and inform its users through the use of mashups on-demand.

It should note that releasing certain business data stored in different enterprise information systems is a common practice for large and medium organizations. This is because an organization often needs data from various sources to be linked intra-organizationally to support its business functions and activities (e.g., presenting a new business model). This makes it possible to pull data from different sources, wrap them in a unified format and publish them as individual data services (e.g., Service A, B,
C). Moreover, third-party Web services (e.g., Service D, E) can be considered for improving the flexibility and usability of final applications.

Once different services are published by organizations, it needs to consider the hosting architecture as it determines how these services can be discovered and accessed by all member organizations. In a DaaS model, it should consider two aspects: (1) services are only needed when necessary and (2) they must allow easy access when needed. For these reasons, the hosting cloud can be either in a linked service cloud or a centralized cloud form.

After all services are hosted and made available to discover, mashups can be used to support inter-organizational data activities through common access protocols. This weaving process allows member organizations to make use of all relevant services in the cloud and create business applications on behalf of their customers (e.g., Situational Applications A) on-demand [9][11]. The benefit is obvious as any member in the network can access any services from anywhere and form its own customized applications at any time.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** The three-tier DaaS model (bottom-up) where data from different information systems of different organizations is gathered and processed (Tier 1), published as services and hosted in the cloud (Tier 2), used to form different situational applications (Tier 3). Services circled with the dashed line indicate a specific situation.</figcaption></figure>

## 4 Case Study

In this section, the UK's national electrical system is used to demonstrate the practical use of the DaaS model during an incident.
## 4.1 An Overview of the UK's National Electrical System

UK's national electrical system is called the National Grid, which is operated by National Grid plc<fnref n="1" /> as a result of the privatization of the Central Electricity Generating Board (CEGB) in 1990s. The three key stakeholder areas in the system are generators, distributors (DNOs) <fnref n="2" /> and suppliers. Note that many large utility companies in the UK are vertically integrated. For example, Scottish Power<fnref n="3" /> [12] operates separate businesses in the areas of power generation, supply and distribution at the same time.

The system operator, National Grid plc owns and operates the National Grid high voltage network in England and Wales. It also operates the transmission network in Scotland. There are seven distributors distributing electricity from the transmission grid to homes and businesses, who are prevented from supplying electricity under the Utilities Act 2000 [13]. There are currently 27 suppliers dealing with electricity supply [14], who make use of the distribution network. Since a distributor owns power lines, transformation centers and substations, it knows exactly how much electricity a household or a business site has consumed in its responsible geographical area but it does not know who is responsible for paying the bill. On the other hand, a supplier knows who is responsible for paying the bill for an address but they do not know how much energy they have consumed. For this reason, the two parties have to work together to bill a consumer correctly. For example, a consumer can submit meter readings to a supplier and a supplier can send inspectors to take meter readings for the consumer. All these information will be later submitted to a distributor for the accuracy check.

## 4.2 Incidents and Communication Issues

The electricity system is complex so incidents can occur at anywhere and anytime. Moreover, with more and more grids are interconnected, an incident in one region can trigger a domino effect that could result in supra-regional blackouts. A prime example is the recent India's blackout, which was initially caused by overloading issues in certain regions but eventually affected more than half the country.

Any incident must be coordinated at system level, which involves the system operator National Grid plc and all seven energy distributors due to regulations. Some industrial users and large business users with interruptible contracts [16] will be informed, too. However, domestic users and most business users will not be communicated promptly. Instead, these users are advised to check with their local distributors on their own no matter if the supplier owns other businesses or not [17] [18]. Nevertheless, timely updates of the progress are not possible for all users. Obviously, when a large power outage happens, it will trigger a chain reaction and

<footnote n="1">¹ http://www.nationalgrid.com/</footnote>

<footnote n="2">² A distributor in the National Grid in the UK is also called a Distribution Network Operator (DNO) [15].</footnote>

<footnote n="3">³ http://www.scottishpower.com/</footnote>
eventually affect the whole community due to the lack of effective communication mechanism inter-organizationally and publicly.

# 5 Implementation Considerations

In this section, we discuss a typical power cut scenario in a regional area in order to demonstrate how to use this model to create an effective communication mechanism between stakeholders and end-users.

## 5.1 Business Requirement

A power cut incident is actually a sudden situation during the normal power supply hence a stakeholder's situational awareness relies on instant discovery and notification of such incidents. This requires instant data access and sharing across all related industrial systems and owners (stakeholders) in the network. As discussed in 4.1, a distributor can discover the incident and rectify the problem but it does not know exactly who are affected and how to communicate them. On the other hand, suppliers have customer details and know how to contact them but they do not know who are affected. Therefore, the following requirements should be formed in an end user perspective:

* A list of substations and servicing areas should be obtained from the distributor.

* A list of affected substations should be obtained from the distributor.

* A list of consumers' addresses should be obtained from the suppliers.

* Consumers must be effectively informed with the problem and the progress through available communication channels provided by the suppliers.

* Consumer energy compensation claiming scheme should be worked out and made available by the distributor.

It should also note that the needs for such an application will only be temporary and these needs will be satisfied automatically when the incident is resolved. That is, the initial development should be reasonably simple and cheap so little time must be spent in the development [19].

## 5.2 Workload Analysis

When active, prompted communication is not available during a power cut incident, a common public reaction is that consumers tend to call their energy suppliers and use other emergency services like 999. The unexpected surge of phone calls often makes related call centers overwhelmed and generates a chain reaction to the community [20]. In this section, we will simulate a supplier's call center's workload for demonstrating why effective communications cannot be guaranteed during an incident and why our model will be useful for solving such issues.
Suppose that a call center takes 70,000 calls a month which indicates 250 calls per normal working hour [21]. Assume the incoming calls behave statistically like a Poisson process in a normal situation and the call center follows common industrial recommendations for services. For example, the SLA is 80/20 and the average call duration is 240 seconds (4 minutes). Using Erlang-C formula below, the number of agents needed is 21.

$$E_c(m, u) = \frac{\frac{u^m}{m!}}{\frac{u^m}{m!} + (1-p) \sum_{k=0}^{m-1} \frac{u^k}{k!}}$$

With 21 agents, when the incoming calls increase to 315 calls per normal working hour, the average waiting time will be **infinite** as shown in Fig. 2. Note that in the event of an incident like Barcelona blackout affecting a high population, the surge of calls will be more radical [22] so that it can easily exceed the simulated critical point (350 calls per hour) within minutes. Therefore, the benefit of an intuitive notification process using available communication means, which is automatically triggered when an incident was identified, is obvious.

<figure><img src="image_3.png" /><figcaption>Fig. 2. The x-axis shows the number of incoming calls per hour and the y-axis shows the average waiting time in minutes.</figcaption></figure>

## 5.3 Situational Application

Based on the above analysis, the distributor needs to publish two data services: a substation-address service and an affected substation service. The suppliers need to publish one data service: customer-notification service. Then a situational application for customer incident notification can be dynamically created by using mashups to integrate these services (Fig. 3.). In other words, once the affected substation service starts pushing out data, it will trigger the execution of the application. Moreover, the application can be more interactive and user friendly by integrating third-party
location based services. For example, in Fukushima nuclear disaster, Google Map has been used to report live nuclear pollution spread-out. A similar approach can be considered in this situation, too. Additionally, with the integration of social networking services like Twitter and Facebook, the application can also extend the reach.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** The incident management SA is created with selected data services published by different stakeholders in the system. Their business data are sourced from different information systems owned by them and wrapped with a universal XML schema for data interoperability.</figcaption></figure>

# 6 Conclusion

Effective incident prediction and forecast can be time consuming, labor intensive and even a mission impossible due to the complexity of large industrial systems. Thus effective incident management is always considered as a more cost-effective solution to reduce the adverse impact on the community and economy when an industrial incident occurs. In an end-user perspective, this relies on instant situational awareness and timely response. The core concept of our model is that it uses DaaS and mashups to help stakeholders respond to emerging situations more intuitively. The model also supports on-demand data access and flexible situational application development which can be used to address timely customer needs. The case study and the simulated analysis show the usefulness of this model in a real practice. It should also note that there are always some typical concerns for DaaS such as data quality and governance [25]. In this model where services are actually released by partnering members in a collaborative network, such issues can be easily resolved by appointing
a central data managing unit to manage data services. Additionally, since user access control can be used for monitoring service access in this model [23], the service log file can also be used to track responsible stakeholders in case some customers are not notified effectively.

**Acknowledgements.** This work is made possible by the support of the Natural Science Foundation of China (NSFC) under Grant No.61150110484, ESSENTIAL: Enterprise Service deSign based on ExistiNg software Architectural knowLedge. In addition, the authors would like to express their appreciation to all reviewers in PRO-VE' 12 and 13 for their constructive comments.

## References

1. BBC News: Hundreds of millions without power in India. http://www.bbc.co.uk/news/world-asia-india-19060279 (2012)

2. LaCommare, H.K., J. H. Eto, J.H.: Understanding the Cost of Power interruptions to U.S. Electricity Consumers. Berk. Lab. Univ. California Berkeley, Berkeley, CA, Contract DE-AC03-76F00098 (2004)

3. Lineweber, D., and McNulty, S.: The Cost of Power Disturbances to Industrial and Digital Economy Companies. CEIDS (2001)

4. Nanto, D. K., William, H., and Donnelly, J. M.: Japan's 2011 Earthquake and Tsunami: Economic Effects and Implications for the United States. Congressional Research Service (2011)

5. Investigation committee on the accident at the Fukushima nuclear power stations of Tokyo Electric Power Company: Final Report. ICANPS (2012)

6. Lowe, D.: Web System Requirements: An Overview. J. Req. Eng. 8, 102 -- 113 (2003)

7. Turner, M., Zhu, F., Kotsiopoulos, I., Russell, M., Budgen, D., Bennett, K., Brereton, P., Keane, J., Layzell, P., Rigby, M.: Using Web Service Technologies to create an Information Broker: An Experience Report. In: 26th International Conference on Software Engineering, pp. 552--561 (2004)

8. Kephart, J. O., Chess, D. M.: The Vision of Autonomic Computing. IEEE Computer. 36(1), 41--50 (2003)

9. de Vrieze, P., Xu, L., Bouguettaya, A., Yang, J., Chen, J.: Building Enterprise Mashups. Future Generation Computer Systems. 27(5), 637 -- 642 (2011)

10. Wang, L., von Laszewski, G., Younge, A., He, X., Kunze, M., Tao J., Cheng, F.: Cloud Computing: A Perspective Study. New Generation Computing. 28(2), 137 -- 146 (2010)

11. Olson, A. J.: Data as a Service: Are We in the Clouds? J. Map. Geo. Lib. 6(1), 76 -- 78 (2009)

12. The Big Six - A Guide to the UK's Top Energy Providers, http://www.which-energy.co.uk/energy-efficiency/the-big-six-a-guide-to-the-uks-top-energy-providers.html

13. Utilities Act 2000, http://www.legislation.gov.uk/ukpga/2000/27/contents

14. Energy suppliers, http://www.which.co.uk/switch/energy-suppliers

15. National Grid: Distribution Network Operator (DNO) Companies, http://www.nationalgrid.com/uk/Electricity/AboutElectricity/DistributionCompanies

16. Baldick, R., Kolos, S., Tompaidis, S.: Interruptible Electricity Contracts from An Electricity Retailer's Point of View: Valuation and Optimal Interruption. Operations Research. 54(4), 627 -- 642 (2006)
17. Emergence Numbers, http://www.britishgas.co.uk/help-and-advice/contactus-personal-details/emergency-numbers.html?bglink_id=i10124

18. Electricity Emergency Information, http://www.scottishpower.co.uk/support-centre/emergency-information/electricity-emergency

19. de Vrieze, P., Xu L., Xie, L.: Situational Enterprise Services. In: Encyclopedia of E-Business Development and Management in the Digital Economy, Hershey, PA. Idea Group Publishing, pp. 892-900 (2010)

20. Bruch, M., Munch, V., Aichinger, M., Kuhn, M., Weymann, M., Schmid, G.: Power Blackout Risks. CRO Forum (2011)

21. The British Gas Customer Panel Feedback Report, http://www.britishgas.co.uk/about-us/about-British-Gas/we-are-listening.html (2010)

22. Peacock, P. J., Peacock, J. L.: Emergency Call Work-load, Deprivation and Population Density: An Investigation into Ambulance Services Across England. J. Publ. Heal. 28(2), 111 -- 115 (2006)

23. Managing Users of Amazon SimpleDB, http://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/UsingIAMWithSDB.html

24. Jiang, N., Lai, X., de Vrieze, P., Lim, M., Jabaro, O.: A Cloud based Data Integration Framework. In: 13th IFIP WG 5.5 Working Conference on Virtual Enterprises, pp. 177 -- 185 (2012)

25. Truong, H., Dustdar, S.: On Analyzing and Specifying Concerns for Data as a Service. In: IEEE Asia-Pacific Services Computing Conference, pp. 87 -- 94 (2009)

26. Rubin, G., Potts, H., Michie, S.: The impact of communications about swine flu (influenza A H1N1v) on public responses to the outbreak: results from 36 national telephone surveys in the UK. Health Technology Assessment. 14(34), 183 -- 266 (2010)

27. Palen, L., Liu, S.B.: Citizen communications in crisis: anticipating a future of ICT-supported public participation. In: SIGHCI Conference on Human Factors in Computing Systems (CHI'07), pp. 727 -- 736 (2007)

28. Papazoglou, M. P., Heuvel, W. J.: Service oriented architectures: approaches, technologies and research issues. The VLDB Journal. 16(3), 389 -- 415 (2007)