Enterprise Modelling and QoS for Command and Control ... - CiteSeerX

Enterprise Modelling and QoS for Command and Control Systems Jan Øyvind Aagedal§ and Zoran 0LORãHYLü‡ § SINTEF Telecom and Informatics, P.O.Box 124, Blindern, N-0314 Oslo, Norway [email protected] ‡ Distributed Systems Technology Centre, University of Queensland, QLD 4072, Australia [email protected]

Abstract This paper presents an approach for enterprise modelling of complex command and control systems. This approach is based on the use of ODP enterprise language concepts (communities, roles, enterprise objects, policies, and contracts), augmented with enterprise-related Quality of Service (QoS) descriptions. These descriptions are based on the ODP QoS statements, namely QoS capabilities, QoS requirements, QoS offers, QoS contracts, and QoS observations. We then present a set of practical guidelines for applying such an extended ODP enterprise viewpoint terminology. The use of these guidelines is illustrated by an example of a command and control system for oil-platform disaster operations. We describe the main communities involved, their roles and policies, as well as key QoS statements for these communities. UML notation is used to represent the concepts described throughout the paper.

1. Introduction Distributed object technology is being seen by many as a key technology in support of virtual enterprises and complex collaboration structures. As this technology matures, it is increasingly being used in organisations to exploit the benefits it provides as a factor leading to competitiveness. Many organisations are deploying distributed object technology (or planning to deploy it in the near future), either to augment or to replace their existing IT systems. However, the deployment of this technology is not an easy and straightforward process. For example, a company needs to consider the various distributed computing platforms available in the market (e.g. presently CORBA, Java-RMI and DCOM) and select the one (or a combination of them) that both fits its evolving business needs, and enables effective

interfacing with the company’s existing IT infrastructure. The early experiences of organisations that have used the first generation of distributed systems, such as DCE, extensively suggest a need for a technology-neutral architecture for supporting their processes, operations and policies. This ensures a focus on the business facets of the enterprise, allowing for an easier adoption or integration of new technologies as they emerge, as is now the case with CORBA or DCOM. We refer to such a technology-neutral and business-oriented architecture as enterprise architecture. An enterprise architecture provides the basis for incorporating new (or extending existing) IT systems, irrespectively of which technologies are (or will be) available in the market as implementation candidates. Enterprise architecture also helps to specify the requirements for IT-support. The requirements are based on a model of the complete system of which the IT systems are only parts. The requirements are not only functional requirements focusing on what the IT systems must be able to do, but also qualitative requirements focusing on how well these systems and their components will perform. Hence, the architecture should not only reflect structural and behavioural, but also quality aspects of an enterprise, including its interactions with other enterprises. This is of particular importance for new generations of distributed applications that are becoming more complex, both in terms of semantics and scale. This complexity in turn requires a disciplined approach to specifying the architecture for these applications. While the existing distributed object technologies provide the basis for building distributed applications, there is no agreed way of specifying architectures for open distributed systems. It is our experience that the Reference Model for Open Distributed Systems (RMODP) [1-3] offers a good starting point for technologyneutral specification of architectures for open

1

distributed systems. RM-ODP provides a rich specification framework for describing behavioural aspects of complex systems, including those that involve a significant human and organisational component. Examples of such complex systems are command and control systems (which, in military context, are referred to as C4I-systems). In addition, the specification framework needs to be able to describe the qualitative aspects of complex systems. The ongoing activity on standardising Quality of Service (QoS) in RM-ODP addresses this problem [4]. When augmented with a precise QoS framework and new extensions to the ODP enterprise language [5], ODP standards can provide a rigorous and technology independent specification framework for all aspects of complex distributed systems. The ultimate goal is to produce a set of tools to be used to facilitate the process of describing and building IT systems that optimally fit the enterprise structure and behaviour. These tools would need to support the enterprise modelling concepts such as policies, contracts, generic QoS descriptions and relationships between these concepts. Although some existing tools support certain aspects of enterprise modelling [6-8], to the best of our knowledge, there are no tools that support the full range of enterprise modelling concepts. In this paper, we show how the ODP enterprise language can be used to model structural, behavioural and qualitative aspects of command and control systems. Section 2 introduces the main ODP enterprise language concepts and the fundamental QoS terms as currently being standardised within ODP efforts. It provides a detailed positioning of QoS within an enterprise specification. This section also outlines some guidelines for enterprise specification based on the ODP modelling concepts. Section 3 discusses our enterprise modelling approach by means of an example of an command and control system to support an oil spill emergency situation. This example illustrates the complexity of an enterprise specification, in terms of the behavioural aspects and the corresponding QoS specifications. We show how different parts of an enterprise specification, corresponding to different parts of the command and control system can have quite varying QoS specifications. Section 4 concludes and indicates our plans for future work on this topic.

2. RM-ODP and Enterprise QoS The ISO Reference Model for Open Distributed Processing (RM-ODP) [1] is an international standard that can serve as a framework for describing architectures of open distributed systems. These systems provide support for distribution, interoperability and portability of applications based on object technology.

RM-ODP standardisation focuses on distributed systems that cross organisational and technological boundaries. An RM-ODP specification of a system consists of five different specifications, corresponding to five different, but related, viewpoints on a system. They are the enterprise, information, computational, engineering, and technology viewpoints. Each viewpoint is an abstraction of the whole system focusing on a specific area of concern. The enterprise viewpoint is concerned with the purpose, scope and policies of the ODP system. When describing a distributed system using the RMODP framework, the RM-ODP enterprise viewpoint is typically used as a first step in the process. The corresponding enterprise language specification is currently being refined and extended to better reflect practical needs for enterprise modelling of real systems [5]. In the section below we summarise the basic enterprise language concepts.

2.1. RM-ODP Enterprise Language Community is the key enterprise concept in RM-ODP [3]. A community is defined as a configuration of objects formed to meet an objective. The objective is expressed as a contract that specifies how the objective can be met. A contract is a generic RM-ODP concept (defined in [2]) that specifies an agreement governing part of the collective behaviour of a set of objects. A contract specifies obligations, permissions and prohibitions for the objects involved. A contract specification may also include the specification of different roles engaged in the contract, the interfaces associated with the roles, quality of service attributes, indications of periods of validity, behaviour that invalidates the contract, and liveness and safety conditions. Therefore, a community contract specifies the roles within a community, the relationships between the roles and various policy statements about the roles and about the enterprise objects which fill them. The community specification also includes the environment contracts that state policies governing interactions of this community with its environment. In situations when two or more groups of objects, under control of different authorities, engage in co-operation to meet a mutual objective, they form a special kind of community, called a federation. A role is a specification concept describing behaviour. A role may be composed of several roles. A role serves as a placeholder for an object. Typically, such a placeholder appears in a template for a composite object, where a composite object is a configuration of interacting objects that offer a composite behaviour. In the enterprise viewpoint a configuration of objects established for achieving some objective is referred to as a community. A role thus

2

identifies behaviours to be fulfilled by the enterprise objects comprising the community. An enterprise object is an object that fills one or more roles in a community. An enterprise object can also participate in more than one community at one time. If an enterprise object has the capability of meeting a role’s behavioural specification, it can fulfil the role, provided it also complies with the policy specifications for the role. Typically, the behaviour of an enterprise object is determined by its individual objectives. The participation of the enterprise object within a community enables the realisation of its additional objectives. The participation is institutionalised by the community contract as introduced above. The contract enables conflicting behaviours of the enterprise objects to be mediated to meet the community’s objective. This is facilitated by the community contract that introduces, through policy statements, separate behavioural specifications about roles. A policy statement provides an additional behavioural specification. It may be either a constraint or an empowerment. Examples of policy statements are the statements of permissions, prohibitions, and obligations related to the roles or to the enterprise objects. In particular, these statements relate to:

1

ODP community 1

1

interaction

ODP community objective 1 expressed as

1..* governed participates by in 1 1 2..* ODP contract

*

1..* ODP-role

1..*

1..* fulfills 1..*

1..*

ODP enterprise object

ODP permission

ODP policy

ODP prohibition

ODP obligation

•

interactions between enterprise objects fulfilling roles, • the creation, usage and deletion of resources by the enterprise objects fulfilling roles, • the configuration of enterprise objects and the allocation of enterprise objects to the roles, and • the environment contracts governing the system. A model of the key enterprise language concepts is shown in Figure 1 using UML (Unified Modeling Language) [9] notation. From this model, specific enterprise models can be derived. Note that ODP policy is an abstract class (shown in italics), so only its subclasses can be instantiated. The specification parts discussed incorporate both the functional and non-functional aspects of the system to be built. The functional aspects relate to the description of what the system does. Non-functional descriptions address how well this functionality is (or should be) performed if it is realised. In other words, if an observable effect of the system doing something can be quantified (implying that there is more than a ‘done’/‘not-done’ effect of the behaviour), one needs to describe the quality of that behaviour. The quantification of quality can be against some commonly agreed reference unit, like delay in seconds, or by ordinal rankings, like a scale from 1 to 5. The former is often referred to as an objective measure, while the latter is a subjective measure.

Figure 1. Model of community concepts

We note that the existing ODP enterprise specification, as presented above, focuses mainly on functional aspects of the system, that is roles, interactions and policies about behaviour. Although non-functional aspects (i.e. QoS) are implied in a number of concepts (e.g. a contract), there are no guidelines as to where to include and how to specify QoS aspects of a system. This is also true for other viewpoint specifications, and work has recently started to extend the ODP standards in order to provide a consistent framework for describing QoS across the ODP viewpoints [4]. In this paper we aim to extend an ODP enterprise specification with QoS statements. To this end, we will examine the structure of the enterprise specification and will endeavour to identify those enterprise concepts that incorporate various QoS statements. To facilitate presentation, we briefly describe different kind of QoS statements in an ODP system, based on [4].

2.2. Quality of Service For many applications, the ability to maintain, configure and predict quality of service (QoS) is essential. QoS is a general term that covers system performance, rather than system operation (i.e.,

3

functionality). A number of different definitions of QoS have been given. The ITU-definition in [10], which we adopt in this paper, states that QoS is “the collective effect of service performances which determine the degree of satisfaction of a user of the service”. The RM-ODP definition of QoS is “a set of qualities related to the collective behaviour of one or more objects” [2]. This generic definition is currently being refined in the context of the new work on QoS in ODP [4]. The main points of this new ODP standard are summarised below. Expressing the total QoS in terms of a set of QoS characteristics facilitates reasoning about QoS. A QoS characteristic represents some aspect of the QoS of a system, service or resource that can be identified and quantified [11]. It represents the true underlying state of affairs (the actual, performance-oriented description of the behaviour), as opposed to any measurement (see QoS observation below). Examples of QoS characteristics are delay, throughput, confidentiality, and precedence. QoS characteristics are to be distinguished from QoS parameters. A QoS parameter is any value related to QoS that is conveyed between entities. There are five categories of QoS statements used when describing QoS (or its constituent QoS characteristics), and subsequently in building distributed systems: i) QoS requirements, which state QoS constraints that users of the system or its components have on the system or its components. They can be expressed using the concept of QoS relation. QoS relation is the most fundamental concept for describing non-functional aspects of ODP systems. It will be described below. ii) QoS capabilities, which state the actual abilities provided by the components or configuration of components in the system with regard to QoS. QoS capabilities can be expressed using the notion of QoS relation. iii) QoS offers, which describe advertised QoS. While QoS capabilities describe actual capabilities of the components, QoS offers are introduced to take into account uncertainty of the knowledge of the actual QoS capabilities of objects. This uncertainty can lead to some discrepancy between an object’s QoS capability and its advertised offer. QoS offers can also reflect the fact that a total QoS capability can be partitioned so that only subsets are available as advertised offers. QoS offers can be expressed using QoS relations. iv) QoS contracts, which are the results of agreement processes. They define the sets of capabilities that objects in a configuration have agreed to provide to each other. They can also be

expressed using the QoS relation concept. They can either be agreed by dynamic negotiation mechanisms or be implicitly incorporated into the design of systems. v) QoS observations, which express the values of QoS characteristics as observed using measurement functions. QoS relation specifies the mutual obligation of an object and its environment with respect to QoS. The QoS relation concept is the most primitive concept for specifying QoS aspects in ODP systems, applicable across all ODP viewpoints. This concept is introduced to model the fact that, in general, QoS provided by an object can also be a function of how the environment performs. For example, the QoS of a multimedia presentation object can depend on the QoS of a video storage service and an associated audio storage service. A QoS relation consists of an expectation part, which describes QoS expectations of an object from its environment, and an obligation part, which describes the object's QoS provision, provided the environment performs according to the expectations. More formally, for an object O, this is expressed through the relation Exp(O) È Obl(O) where ‘È’ is a form of logical implication that can be read as ‘constraint Obl(O) is met as long as constraint Exp(O) is met’. QoS relations can be composed to be applicable to a composition of objects. For further information on the composition, see [4].

2.3. QoS in Enterprise Specifications In this section, we identify those parts of an enterprise specification to which QoS statements can apply. This is done by examining the enterprise concepts, as they are introduced in 2.1, and extending them with QoS statements from 2.2. Community contract: A community contract specifies the roles within a community, their relationships, and various policies associated with the roles and the community and its environment. Each of these concepts carries the notion of QoS, and these are discussed below. Role: When specifying certain type of roles, QoS requirement statements are needed. For instance, in the case of a role that models behaviour of a service user, QoS requirements state the constraints they have on the service characteristics. These depend on the service in question, e.g. minimum resolution of electronic charts for a GIS-service (Geographical Information System) or maximum lip-synch variation tolerance for a multimedia presentation service. Other kind of roles need specification of QoS offer statements for describing

4

quality of their behaviour that should be measurable after the behaviour is instantiated. For example, this can be applicable to a role that models a service provider. In this case, QoS offers state the advertised QoS value of a service provider role. In addition, there may be separate QoS policy specifications, such as those describing permissions about the range of QoS characteristics that an object may provide to fulfil a role, or those policy specifications describing obligations for undertaking certain actions in cases where QoS is below permitted lower bounds. Enterprise object: QoS statements for an enterprise object depend on its behavioural type, which in turn originates from its objectives. In the case of an enterprise object representing a service user, QoS statements typically express QoS requirements; in the case of a service provider they express QoS offers or QoS capabilities, depending on the context. For example, a service provider can choose to make available its full capability set to its users, or it may decide to partition its capability set into several offers according to particular user requirements. Further, during the process of assigning an object to a role, it is not sufficient to ensure the matching of their behavioural specifications. It is also essential that their QoS specifications are matched. The policies related to the assignment of roles to enterprise objects should incorporate these rules. If an object fulfils multiple roles, a policy statement (on this enterprise object or on a composed role) should describe how to address the composition of QoS relations. The policy statement should also, where necessary, describe how to address possible conflicts arising, for example, from the situation in which the same object is performing different activities in different communities. Policy: The policy statements introduced as part of a community specification do not make a clear distinction between functional and non-functional aspects. For instance, the policies governing interactions between enterprise objects should take into account QoS requirements related to the interactions, such as requirements for maximum delay between a service request and its response. Further, policies related to the creation, use and deletion of resources by the enterprise objects can state QoS requirements on the resources. For example, if the resource is a weather forecast, QoS requirements could quantify service characteristics such as freshness (i.e. how up-to-date the information is), accuracy, reliability and availability of weather data. In the case of policies related to the configuration of enterprise objects and the assignment of roles to them, there may be significant QoS requirements that influence the partitioning of their functionality. This is in order to satisfy some availability and security

constraints, as well as to elaborate security policies regarding the assignment of objects to roles.

2.4. Guidelines for ODP Enterprise Modelling In order to exploit the ODP enterprise concepts presented earlier, it is useful to have a methodology that guides the process of enterprise modelling. We outline a methodology that consists of a number of steps, as follows. 1. Describe the area of interest informally. This serves the purpose of scoping the problem domain, focusing discussion on concepts relevant to the domain of interest. 2. Identify the communities in the domain, based on their respective objectives. 3. For each of the communities, identify the interactions with other communities and federations that they may form. 4. Define a community contract for each of the communities. This includes definitions of roles, their relationships, and policies, as elaborated below. 4.1. Identify the roles within the communities. 4.2. For each of the roles within a community, specify its abilities and/or requirements (including QoS offers and/or QoS requirements when relevant). Also, provide policy statements about roles (e.g. permissions, prohibitions, and obligations). 4.3. Within each community, specify the relationships between the roles, both in terms of interactions and policies (including QoS policies when relevant) related to the interactions. 4.4. For each relationship that includes qualitative aspects, identify the QoS requirements and QoS offers of the involved parties, and specify a QoS contract. We note that these guidelines should be included in a more comprehensive methodology, but this is a topic for future research. The steps described may not necessarily be done sequentially, and results from an earlier step may be revised after new knowledge is gained in a later step. UML is the predominant notation for expressing analysis and design models, and can also be used to express enterprise models. UML includes OCL (Object Constraint Language) [12] which is designed to express side-effect-free constraints and other expressions attached to the models. OCL can be used to express QoS constraints and to formally define contracts between roles. In the next section we will show an example of enterprise modelling using UML.

5

3. Example In this section, we illustrate the enterprise modelling and related QoS specifications discussed in the previous sections with a simplified example of a command and control system for an offshore oil spill situation. The example illustrates many concerns which are also relevant also to military command and control systems, known as C4I-systems (Command, Control, Computer, Communications and Intelligence). Military issues such as situation awareness, mission definition, identification of roles, resource availability and quality requirements are important enterprise concerns. These concerns are formally embodied in the so-called operations order, which represents spatial, temporal and organisational patterns of behaviour. In particular, this example demonstrates: •

• •

helicopters that can reach the platform for rescue or environmental operations. The crisis team is located in the headquarters (HQ), and it consists of members from the rescue team (for example the coastguard), the oil company operating the platform, and representatives from the Department of the Environment. When the oil spill is first detected, it covers 2,000 m2. Based on an unreduced production rate, the oil spill will increase to 24,000 m2 within the next 6 hours. The installation is 10 km east of the shoreline. The wind is 7 m/s NE threatening to spread the oil spill towards nearby protected wetlands. The visibility is 500m, the waves are approximately 1 metre, the air temperature is 17 degrees Celsius and the water temperature is 14 degrees Celsius. Hospital

The complexity of enterprise modelling of command and control systems encompassing various communities with different kind of roles, both the automated entities and human actors; in other words, the complexity of an enterprise architecture for such systems. The variety of enterprise QoS descriptions pertinent to such systems.

HQ

The positioning of the relevant aspects of the underlying distributed object technology that supports the enterprise architecture.

Computing centre

3.1. Scenario – informal description An uncontrolled flow of oil and gas (blow-out) occurs on an offshore drilling platform (see Figure 2). An emergency situation arises with a fire on board that threatens the whole installation. The highest priority emergency alarm warns the platform supervisors on shore, and following this a crisis team is immediately established according to a predefined emergency plan. Firstly, the crisis team is responsible for assessing the situation and planning and co-ordinating activities associated with rescue operations. It will issue commands and will control the activities of professional rescuers to rescue people from the platform. In addition, the crisis team is also responsible for the maintenance of the rest of the production (if possible) and prevention of further oil spill. For this, it should coordinate activities of different platform experts. Finally, the crisis team should also supervise subsequent cleanup operations, undertaken by oil-retention vessels. The crisis team will consult marine biologists, medical experts, the computing centre (for oil drift calculations) and the Weather Bureau as required. The crisis team may also use the services of surrounding vessels and

Weather Bureau

Oil platform

Figure 2. Scenario

The tasks for the crisis team in order of priority are: 1.

2.

3. 4. 5. 6. 7. 8.

Immediately implement the predefined crisis plan that prescribes a clear command and control structure for life-rescue operations (this corresponds to the operations order in military terms). Assess the situation and take actions to prevent potential loss of human lives due to subsequent uncontrolled events. These actions should be initiated within 30 minutes from when the emergency situation was first reported. Evaluate measures to get control of the situation, including deciding whether to stop production. Establish public relations, including an emergency telephone number for relatives. Assess environmental impact. Prevent further spreading of toxic compounds, including the oil spill. Collect and remove the oil spill. Clean up the coastline, if necessary.

The weather conditions play an important role in taking proper decisions. In the rescue operations, wind,

6

temperature, visibility and waves will influence which actions to take. The external conditions, including weather, also influence the clean-up operations. Oil retentions (booms) may be used if the waves are small; the evaporation increases with temperature, and bacterial or chemical substances may be sprayed on the oil spill to reduce or dissolve it if such measures are environmentally safe under the current conditions. The resources available for the tasks mentioned above are limited, and certain trade-off decisions have to be made that take into account priorities assigned to the tasks and the characteristics of these resources. For example, in case of rescue operations, all available resources must be used to their full capacity without considering cost. Further, available air and sea vessels all have different characteristics. Aeroplanes are expensive to use, but can sweep large areas in search of people in need of rescue. Helicopters are also expensive in use, but can evacuate people in need of rescue while still transporting them fast to shore. However, helicopters have a limited range of operation because they must frequently return to re-fuel. Sea vessels are not so expensive in use, but have a limited range of operation and they are slow. However, they can scrutinise smaller areas and also reach closer to the platform. The rescue operation co-ordination should maximise utilisation of the available resources based on their characteristics. In the case of clean-up operations, there is a trade-off between cost, environmental impact and the degree of clean-up. To spray chemicals onto the oil spill in order to dissolve it is a cheap solution, but it may not be environmentally viable. To clean the shoreline of oil pollution is very costly and time-consuming; if possible, it is better to try to retain and collect the oil spill out at sea. Stopping oil production is very costly. After an emergency stop, it may take a long time before production is back to normal; meanwhile the oil platform operator is losing money. Communication and computing technology plays a critical role in carrying out tasks assigned to different teams in rescue, blow-out control, clean-up and other operations. It enables continuous communication between these teams and visual monitoring of the situation. These technologies also enable early detection of emergency situations and calculation and prediction of weather conditions, oil spill drift, and so on. In particular, the use of modern distributed object technology enables interoperability between various IT subsystems supporting these kind of command and control systems. This technology also enables integration of legacy systems into the overall architecture. Some of the key subsystems will be discussed in more detail in 3.3, 3.4 and 3.5.

3.2. Communities Based on the informal description of the area of interest in the previous section, we begin by specifying a community contract for all the roles involved in the oil disaster situation. This includes the roles of the following teams: crisis team, rescue team, blow-out control team and cleanup team, as well as the roles of a medical professional, weather bureau, marine biologist, calculation centre and the public. The aforementioned teams can be further refined as communities, which, in their own rights, are specified by the corresponding community contracts, including their own roles, relationships between the roles and policies that apply to them. These contracts express the objectives of the communities. These objectives are listed in Table 1. Table 1. Communities and their objectives

Community Crisis team

Rescue Blow-out control Clean-up

Objective Facilitate efficient communication amongst people from different communities located in the HQ. Fast transport of people in danger to a safe place. Stop the fire and contain and stop the blow-out. Limit the environmental damages.

For the purpose of this example, we will be focusing on specifying the crisis team, rescue and cleanup communities. Other communities (e.g. public and medical) are not of special interest and will not be discussed in the example. In Figure 3, we show the communities identified along with the interactions between them1. For example, the interactions between crisis team and public communities can be described by a contract that states mutual obligations and policies reflecting background rules of the “outer community” (for example government regulations about provision of timely information). In the following, we address the problems of specifying various aspects of different communities, and for this we focus on the specification of crisis team, rescue and clean-up communities. We start with a description of the crisis team community because it illustrates a number of interesting relationships of this community with its peer communities and with the outer community. The crisis team community also illustrates some conflicting behavioural patterns when the same enterprise object fills several roles in different 1

We have omitted the cardinality specifications in Figure 3 since all relationships have cardinality of 1 at each end.

7

communities. Next we describe the rescue community to illustrate how to specify a community contract by identifying the roles, describing their abilities and the Medical community

Public community

informs

Blow-out control community

informs

alerts

Crisis team community informs

Calculation centre

informs

uses

Clean-up community

Rescue community

uses uses Weather Bureau

uses

Marine biologist

Figure 3. Communities and their relationships

relationships between the roles. The specification of the rescue community also illustrates how to use UML in community specifications, and shows how to consider initial QoS specifications. The final specification of the clean-up community illustrates how role interactions and QoS can be specified in more details, and shows that automated entities as well as human actors can fill roles within a community.

3.3. Crisis team community The roles in the crisis team are liaison officers for rescue operations, blow-out control operations, clean-up operations, and public relations. These roles communicate information amongst themselves about current development of the situation. These roles are the counterpart roles of the crisis team community to the corresponding roles in the rescue, blow-out control, clean-up, and public communities. Typically, the enterprise objects (or their delegated objects) that fill these roles in the crisis team will also fill the counterpart role in the corresponding community. For example, the enterprise object that fills the rescue operations liaison officer role would normally fill the role of rescue commander (as presented in 3.4) in the rescue community. This can be specified as a policy constraint in an outer community for the communities in question. In our example, the outer community corresponds to the

authorities that define the crisis plan and the laws and regulations, namely the government. An alternative specification for these ‘counterpart’ roles of the crisis team and other communities could be in terms of the composition of behaviour corresponding to these roles. For example, the separate behaviour specifications associated with the rescue operation liaison officer role and rescue commander could be composed to produce a composite role, and such a role would appear in the specification of both crisis team and rescue communities. The enterprise objects that constitute the crisis team community will join and leave the community over time according to the fulfilment of the individual communities’ objectives. For example, members of the rescue community will only be part of the crisis team community until everyone is brought to safety and debriefing has taken place. This means the rescue operations liaison officer role will only be filled as long as the rescue community exists. Another role in the crisis team community is an environmental oil-expert. This role brings into the crisis team community an authority to define obligation for the member roles of the clean-up community. In other words, it sees to it that the clean-up operations focus on minimising the environmental impact. The authority can be understood as a reflection of a policy set up by the Department of the Environment, as an outer community. Following military terminology, this role is of tactical significance, while the clean-up commander is at an operational level. It is interesting to discuss some issues related to potentially conflicting behavioural patterns of enterprise objects filling roles in different communities. Let us assume that one enterprise object is to fill a role of clean-up commander within the clean-up community as presented in 3.5. This enterprise object is also a member of the platform operator community (consisting of the employees of the platform operator company). Members of this community are obliged to share the objectives of the company. Thus, it is possible that the platform operator would like to keep production going despite a high risk of escalating the environmental problems. On the other hand, the clean-up community has the objective to limit the environmental damage, and must act according to the government laws and regulations. This means the platform operator cannot put profit ahead of severe environmental damage. Since the platform operator community and clean-up community impose conflicting objectives on the enterprise object filling the corresponding roles, a priority scheme must be established to resolve these kinds of conflict. Thus, the behaviour of this enterprise object will be governed by a set of obligation policies that incorporate these priorities.

8

3.4. Rescue community The roles in the rescue community are rescuer, rescue commander and rescuees (referring to people needing rescue). A rescuer can be either an air rescuer or a sea rescuer. An air rescuer has the obligation to try to find people in need of rescue, either in the water or on the platform, and inform by radio the rescue commander of their exact position. They can use helicopters or aeroplanes. If using a helicopter, an air rescuer is permitted to take local decisions on whether to evacuate rescuees and whether to transport them to a nearby vessel or on shore. Alternatively, a sea rescuer can evacuate the rescuees. Sea rescuers have similar obligations to air rescuers, but they use sea vessels to perform the operations. The obligation of the rescue commander is to co-ordinate all rescue operations and direct the air and sea rescuers into position. The rescue commander decides whether to use helicopters, aeroplanes or sea vessels depending on the reported situation (that is, visibility, wave height, and so on). The rescue commander uses an automated tracking system to monitor the position of each vessel. The system is also able to calculate where the vessels may reach within a certain time limit. The tracking system has a web-based graphical interface enabling it to be accessed from an ordinary web-browser. The system can also be accessed by a GIS-system that enables constant plotting of positions. The tracking system automatically communicates to the corresponding systems on board the vessels whenever a new position or other information is conveyed. Communication is through a satellite link that can deliver 9.6 kbit/s. It is assumed that the rescuees are mostly passive, but they may contribute with inside information regarding the situation on the platform. The information will vary in precision and accuracy, but it should nevertheless be conveyed to HQ as soon as possible along with a detailed description of the observer and the situation at the time of observation. Information from the rescue community is used to alert the medical community of the severity of the situation. However, it is not the responsibility of anyone in the rescue community to alert them; this is done by the rescue liaison officer role in the crisis team community, as presented in 3.3. For this, one needs to specify two contracts as shown in Figure 4: (1) a contract between a rescue commander role from the rescue community and rescue liaison officer role in the crisis team, and (2) a contract between the liaison officer role and the medical co-ordinator.

Rescue commander

Rescue community

Rescue liaison officer

Crisis team community

Medical co-ordinator

Medical community

Information update contract

Notification contract

Figure 4: Contracts between communities

The model in Figure 1 representing the structure of a general community can be used as a structural pattern (template) to specify concrete communities with their own roles and objectives. Using UML notation, one way of representing a community pattern is as a collaboration. A collaboration can be viewed from the outside as a single entity. In our case we can use the general community contract pattern and parameterise it with specific roles and objectives from the rescue community. Each of the parameters are specified as UML roles. This is shown in Figure 5. RescueObjective Rescue Commander ODP role

Rescuee

ODP role

ODP objective

Community contract

ODP role

ODP contract

Rescuer ODP contract

EvacuateContract

RescueContract Figure 5. Rescue community model

Rescue commander, rescuer and rescuee are roles in the rescue community, all specified as parameters to the

9

community pattern. A rescuer is actually an abstract classification in this diagram, as it can be either an air rescuer or a sea rescuer. The objective of the community is shown as a note attached to the community pattern. The two contracts are also parameters to the pattern, governing the interactions between the roles. They will be discussed in more detail below.

:Rescue Commander 1.

2.

:RescueContract

:Rescuer :EvacuateContract

3. :Rescuee 1. 2. 3.

findRescuees sitingNotification evacuate Figure 6. Role interactions

The behaviour of the roles in the rescue community is shown in a collaboration diagram in Figure 6. The rescue commander is an active role that requests the rescuer to search for rescuees, and the rescuer notifies the commander when they find one. The rescuer also evacuates the rescuee; this is governed by the evacuatecontract. The obligation of the rescuer to notify the rescue commander is stated in the contract between them – the rescue contract. Parts of the contract can be specified using OCL, for example the obligation for a rescuer to tell the rescue commander of any rescuees spotted can be stated as: Rescuer.spotted() implies sitingNotification(position) and position.AccuracyRadius < 50 reading that when the status function spotted() evaluates to true, the sitingNotification will be sent with the position as parameter, and the position is accurate down to a 50 metre radius. The crisis plan states that actions should be initiated within 30 minutes from when the emergency situation was first reported. This means a rescue commander should be operative and have issued orders to the rescuers within that time-frame. A QoS contract for the

rescue commander specifies that the time difference between the emergency message from the platform and the issuance of the findRescuees request is less than 30 minutes. The occurrence of these events can be measured and this can be used to check whether the contractual obligations of the commander are met. However, the high priority of the rescue operations requires additional guarantees that this QoS contract be fulfilled. These imply quite stringent preconditions on the behaviour of the commander. First, there should be a requirement that the person to fulfil the commander role has the ability to be a rescue commander as determined by appropriate bodies. Second, there could be additional policy statements about this person that would prohibit him/her from filling any other role in any community, thereby ensuring the maximum availability of resources from that person within the 30 minutes time interval. More formally, this can be specified in OCL as: communities->forAll( not( ( roles->reject( role | role = RescueCommander))->exists( role | Obj(role) = Obj(RescueCommander)) )) or Obj(RescueCommander) = NIL This can be read as “for all the roles, except the rescue commander role, in all communities, there does not exist any object filling both the rescue commander role and any other role”. We here assume that the set of all communities and the set of all roles are denotable entities. We also assume that there is a function that returns the identity of the object filling the role, or NIL when the role is not filled. However, this requirement may be too restrictive. We need the rescue commander role filled, even if this means the person filling it are simultaneously filling other roles. A less restrictive requirement is that the person filling the rescue commander role should be the least committed of the available candidates, i.e., the person filling fewest roles. This restriction can be formally specified as a rather complex OCL-expression, left out for brevity. The rescue community includes some other role interactions in addition to those depicted in Figure 6. For example, we need to include the role of the automated tracking system, as shown in Figure 7. This system enables the rescuers to automatically report their position on a regular basis to the rescue commander. The interaction between the tracking subsystem on mobile stations (e.g. on the sea vessels or aircrafts), and the subsystem at the fixed station (in the HQ) can be mediated by an appropriate middleware technology. However, we note that all communication between rescuers and HQ uses the limited resources of a satellite link. As a result, an optimal frequency for the

10

notifications should be selected in order not to saturate this network with traffic.

:Rescue Commander

:Rescuer :Rescuers

This is a high-level QoS relation and needs to be further refined with the specifics of QoS characteristics for weather forecast, tracking system and decision support system. A discussion of these specific details is however beyond the scope of this paper.

3.5. Clean-up community mediates

mediates :Mediator bandwith=9.6

Figure 7. Tracking system

In Figure 7 we show the relationships between the roles in the tracking system. Note that the rescuers are represented by the multi-object concept in UML. This is to capture the fact that multiple enterprise objects will fill the rescuer role. The mediator is responsible for transferring information between the parties, but is restricted by the bandwidth available. We can choose to let everyone have an even share of the bandwidth, or we can have a more advanced priority scheme. In any case, we can put precise restrictions on each rescuer’s communication to the mediator by attaching constraints to the relations in Figure 7. One constraint is that the throughput on the communication between the roles (represented by the mediates-relations) cannot be more than the bandwidth of the mediator, or more formally: RescueCommander.mediates.throughput