A Scenario-Based Service-Oriented Rapid Multi-Agent ... - CiteSeerX

A Scenario-Based Service-Oriented Rapid Multi-Agent Distributed Modeling and Simulation Framework for SoS/SOA and Its Applications1 W. T. Tsai, C. Fan, Z. Cao, B. Xiao, H. Huang, W. Song, X. Liu, X. Wei, R. Paul*, Y. Chen, D. Zhang, and J. Xu Department of Computer Science and Engineering Arizona State University, Tempe, AZ 85287 * Department of Defense Washington, DC

Abstract The paper presents a scenario-driven multi-agent framework for rapid simulation generation and verification. Specifically, this framework has the following features: 1. Formal scenario model: This framework uses a formalized scenario model, and in this model each scenario is specified according to the ACDATE (Actors, Conditions, Data, Actions, Timing, and Events) model. Once a scenario is specified using this model, it can be analyzed by various static analyses including completeness and consistency analysis. 2. Automatic code generation: Once system scenarios are specified, the framework can generate its corresponding code. The code can then be used for simulation or implementation. 3. Hierarchical model: This framework can model complex systems by providing a hierarchical modeling scenario model. 4. Multi-agent simulation: This framework can simulate autonomous agents, and each agent behavior is specified using the hierarchical scenario model. 5. Formal policy specification and verification: This framework also supports formal policy specification, and once policies are specified, they can be enforced during simulation to perform dynamic verification. The policy speciation language is also based on the scenario model. 6. Distributed service-oriented simulation: The simulation is performed by distributed agents implemented as web services running on a network. 7. Verification and Validation: This framework has a variety of verification and validation techniques such as Verification Patterns (VPs) and completeness and consistency checking (C&C). The VPs allow test scripts to be generated rapidly from the scenario specification with automated pattern recognition. An early version of this framework has been developed and used to simulate a large real-time distributed C2 (Command and Control) application and discovered numerous faults in the specification. 1

This research is partially supported by NSF and USF/NISTP

1

Keyword: Scenario-driven modeling, automated code generation, distributed simulation, multi-agent simulation, verification and validation, policy specification and enforcement, dynamic verification, service-oriented architecture, web services, verification patterns, completeness and consistency checking, test coverage, automated test script generation

1. Introduction

Recent advances in computer and information technologies accelerate the construction of systems of ever-increasing complexity [4]. The ability to analyze and manage the complex systems is not as fast as the system evolution unfortunately [4]. Simulation modeling and analyses is a practical way for assessing the performance of such complex systems since analytical approach may not available exist [4]. However the traditional simulation is done in a specify-and-code or model-and-code manner, which means that after engineers construct the target system model, engineers must develop the simulation code to run the simulation. This is an expensive approach. This paper proposes a service-oriented scenario-based multi-agent framework for model-and-run or specify-and-run simulation. Once the target system IASM model is constructed, no additional simulation coding effort is needed to run the simulation. Even the real target system’s code can be automatically generated from the system model with no or little human involvement. Multi-agent distributed simulation provides the flexibility, modularity and scalability desired for simulating complex systems. An important advantage of multi-agent simulation is that multiple autonomous agents can be independent developed but simulated together to see the overall system behavior. Thus multi-agent simulation is more suitable to simulate those systems where no single entity has the complete control, e.g., trading markets or battlefield management. As systems become complex [5][4][20], distributed simulation, i.e., concurrent simulation programs running on a network [5], received significant attention because it has the potential to reduce execution time and fault tolerance computing [5]. Another new software development is Web Services (WS) and Service-Oriented Architecture (SOA). Recently, almost all major computer companies such as IBM, Microsoft, Oracle, Sun Microsystems and SAP are moving their software into SOA, and even DoD is moving into SOA projects such as DISA’s NCES, Air Force’s JBMC2, Army’s FCS, OSD’s GIG-ES, and Navy’s FORCEnet. WS allows software components to be discovered, located, bound, executed, replaced, monitored, and verified in real time and at runtime. Another interesting idea is software agents, agents are often used in simulation modeling [18] and simulation such as in SWARM, Magicweaver, MASS, ARCHON, ZEUS, Extend, and so on. These existing software agent-based simulation frameworks are

2

usually only for a narrow specification domain. For example, the Magicweaver is only used for simulation of wireless sensor networks. Some other issues observed include low reusability of legacy simulation models and code, low interoperability of other simulations, deep understanding of technical details and good programming skill are required to work with these frameworks, runtime dynamic simulation (re-)configuration and (re-)composition support and automated dynamic simulation-based analyses support are not ready yet. The proposed framework is a single architecture framework that can be used for both simulation and system development, because it was evolved from system testing and system development into simulation. The simulation engine also allows engineers to participate in the simulation as a live object [18].

2. Scenario Model IASM

This project use a formalized scenario model IASM (Integrated ACDATE/Scenario Model) to model system behavior.

2.1. Basic IASM Modeling Methodology IASM modeling process enhances and formalizes the SRI’s scenario planning process [17] as shown in Figure 2.1: Strategic Decision(s)

Key Decision Factors [ACDATE Elements]

Environment Forces [Environment Modeling and Simulation]

Scenario Logics [Scenario Model]

Strategy Implications [Policy Checking and Enforcement]

Scenarios [Scenario Based Simulation]

Figure 2.1: Enhanced and Formalized SRI’s Scenario Planning Methodology

3

The advantage of SRI’s methodology includes: • The methodology is relatively simple and complete transparent. It is easy for users to follow and put into practice • The process is highly flexible, without depending on the needs and structure of any computer model • A premium is placed on the identification and clarification of issues. The ‘logics’ and structure of the scenarios are, essentially, a construct of the mind. This fact imposes on the team a disciplined need to examine, carefully and critically, every key issue and uncertainty in order to clarify the reasons for differing future possibilities • There is a high degree of ‘ownership’ in the final product. The scenarios have been created by the team, and the resulting sense of ownership is absolutely essential for effective use of the scenarios in strategy planning Comparing to SRI’s methodology, there are several differences (improvements): • IASM provides more enhanced static model analysis methods such as model checking, model verification and validation and so on. • In our IASM, the key decision factors will affect the scenario logics to reflect the real purposes of the scenarios • Scenarios can be automatically converted into executable simulation code. And the result of the simulation can be used to enhance the original scenarios. Thus the decision making process is improved by this iterative modeling and enhancing • Environmental forces are also modeled using IASM, which provides a unified modeling and analysis method for both the target system and the environment • Policy can be enforced during the simulation to check the scenarios modeled by the users ACDATEP is the building block of the scenario model. The target system is decomposed into a set of A (actors), C (conditions), D (data), A (action), T (timing), and E (events), and P (policies): Actors: An actor is an external user, system or device, or an internal system, device, component or object; Conditions: A condition is a predicate used to trigger an action; Data: Attributes of actors, conditions, events, and actions. Actions: An action is a computation, and it is triggered by an event or condition, and the computation can change data and generate other events Timing: This is related to time and timeliness such as deadline and delays. Events: External/internal significant occurrences that may trigger action(s)

4

Policies: These are constraints that an Actor must comply with. The following figure illustrates a simple example scenario: "when both the driver and passenger door are locked, if remote controlled is pressed unlock, then the driver door is open":

Figure 2.2: Sample Scenario and ACDATE Elements System development starts from specifying elements in the ACDATE model. Once the ACDATE specification for a system is ready, an engineer can build the scenario model for both the system and its environment. Since the environment may also impact the target system behavior, it is necessary to take the external environment into account when modeling the target system. Once the scenario model specifications are finished, engineers can perform a variety of static analyses on the model such as C&C (completeness and consistency) checking, see Section 7. After the model has shown to be reasonably consistent and complete, the model can be simulated without any simulation programming. During simulation both the environment and the system will be simulated, and at the same time a variety of dynamic analysis can be performed. Specifically, the proposed framework can check various policies, both global and local policies, are enforced during simulation and report any violation of these policies. Model Element Actor

Element Denotation Ai, i = 0, …, N

Condition

Ci,m, m = 0, …, Mi

5

Denotation Explanation N is the number of Actors in the IASM model Ci,m denotes the mth Condition element of Actor Ai. Mi is the number of Condition elements that

Data

Action

Local Policy

Global Policy

Event

Scenario

Actor Ai owns. Di,j denotes the jth Data Di,j, j = 0, …, Ji element of Actor Ai. Ji is the number of Data elements that Actor Ai owns. Acti,v denotes the vth Action Acti,v, v = 0, …, Vi element of Actor Ai. Vi is the number of Action elements that Actor Ai owns. LPi,q denotes the qth Policy LPi,q, q = 0, …, Qi element that imposed on Actor Ai. Qi is the number of such Policy elements that Actor Ai owns GPq, {i1, i2, …, ix}, q = 0, …, Q GPq, {i1, i2, …, ix} denotes the qth policies that imposed on a set of Actors in the set defined as {i1, i2, …, ix}. Q is the total number of such policies. Ei,k denotes the kth Event Ei,k, k = 0, …, K element of Actor Ai. K is the total number of Event elements that Actor Ai owns. Scnri,w denotes the wth Scnri,w, w = 0, …, W Scenario element of Actor Ai. W is the total number of scenarios that Actor Ai owns. Table 2.1: Modeling and Simulation Notations

2.2 System of Systems (SoS) Modeling A system can be actually a System of System (SoS). For example, a typical DoD system is often a SoS where the system has multiple sub-systems involved. A typical SoS often has a layered architecture that the high-level systems are composed of lower-level subsystems, which in turn may be composed of even lower level sub-subsystems as shown in Figure 2.3. In this way one can classify all systems into two categories: an atomic system and a SoS. An atomic system is a system that currently cannot be divided into lower subsystems.

6

IASM modeling paradigm supports model decomposition to specify the constituent subsystems and the fundamental relationships among these subsystems. The goal is to achieve a SoS perspective for viewing the entire system. As well the scenario specifications address the task execution process within each sub-system which expands the scope of model application to support the management of the operational systems [4]. IASM can be performed in either top-down or bottom-up manner to specify a SoS. Usually if one starts from the requirement phase, a top-down process is a better choice, in which the engineers can start from the top-level system and decompose it into lower-level sub-systems until atomic systems are reached. On the other hand, when most of subsystems are already available, one may want to construct the model in a bottom-up manner where low-level components are used as building blocks to construct high-level systems. System at Level N

System at Level N – 1

▪▪▪▪▪▪

▪▪▪▪▪▪

System at Level N – 1

▪▪▪▪▪▪

System at Level 0

System at Level 0

▪▪▪▪▪▪

Figure 2.3: Layered SoS Architecture Top-Down SoS Modeling Top-Down IASM modeling techniques requires proper decomposition of both ACDATE and Scenarios. Starting from the highest level system, one can come up with a set of ACDATEs and Scenarios specifying the target system. This is illustrated using a car alarm example. Let’s take a simple example into consideration to see how the top-down modeling is used. Say we have a car alarm system which is composed of two subsystems: • Alarm Sensor • Alarm Horn. Table 2.2 shows a part of car alarm system IASM specifications at the highest level. Once the top level system is specified using IASM, it can be decomposed into two subsystems: Alarm Sensor and Alarm Horn, which are two Actors at the lower level, as shown in Table 2.3 and Table 2.4. Actor

A1: Car_Alarm

7

Condition

Data Action

Event Scenario

C1,1: Power_Is_On [Power == On], C1,2: Power_Is_Off [Power == Off], C1,3: Legal_Operation [Operation == Legal], C1,4: Illegal_Operation [Operation == Illegal] D1,1: Power [On/Off] D1,2: Operation [Legal/Illegal] Act1,1: Turn_On_Horn, Act1,2: Turn_Off_Horn, Act1,3: Turn_On_Sensor Act1,4: Turn_Off_Sensor Act1,5: Get_Horn_Status Act1,6: Get_Sensor_Status, Act1,7: Get_Operation_Info_From_Sensor E1,1: User_Operation, E1,2: Thief_Operation Scnr1,1 – Beep three times on Illegal Operations: Using ACTOR:Alarm; while(Power_Is_On){ do ACTION:Car_Alarm.Get_Operation_Info_From_Sensor if(CONDTION:Car_Alarm.Illegal_Operation) then { do ACTION:Car_Alarm.TurnOnHorn do ACTION:Car_Alarm.TurnOffHorn do ACTION:Car_Alarm.TurnOnHorn do ACTION:Car_Alarm.TurnOffHorn do ACTION:Car_Alarm.TurnOnHorn do ACTION:Car_Alarm.TurnOffHorn } } Table 2.2: Partial Simplified Car Alarm IASM Specifications

From Tables 2.2, 2.3 and 2.4, one can see how the top level system is decomposed into the two sub-systems and their relationships. For example, top level Condition C1,1 is decomposed into lower level Conditions C2,1 and C3,1, which means when both C2,1 and C3,1 are satisfied, C1,1 is also satisfied. Similarly for Condition C1,2, but this time when both C2,2 and C3,2 are satisfied, C1,2 is also satisfied. Noticing that there are four possible combinations of the lower level conditions, here only the interested condition decomposition are discussed. Other combinations can be represented as other higher level conditions. Condition C1,3 (Legal_Operation) and C1,4 (Illegal_Operation), they are decomposed to the Alarm_Sensor’s conditions C2,3 and C2,4. Other ACDATE elements can be similarly decomposed. The most interested part is how the upper level system scenarios are decomposed into lower level system scenarios. Taking the three scenarios given in the example, the high level scenario Scnr1,1 is decomposed into two low level scenarios Scnr2,1 and Scnr3,1. At

8

the top level, the Car_Alarm Actor checks the operation type by performing the Action Get_Operation_Info_From_Sensor. At the low level, the operations come to the Alarm_Sensor as an Event (User_Operation/Thief_Operation). Once the Event of Thief_Operation to the Alarm_Sensor Actor, the Alarm_Sensor Actor will update its information of the outside world by setting the Data C2,2 (Operation) to "Illegal" and send out an Event E2,3 (Inform_Horn_Of_Illegal_Operation) to let the Alarm_Horn Actor to know an illegal operation has been performed. When the Alarm_Horn gets the alert from the Alarm_Sensor (by receiving the EventE3,1 – Inform_From_Sensor_Of_Illegal_Operation), the Alarm_Horn will beep three times, which corresponding to the three cycles of turning on and off the Alarm_Horn. One can see that the Events play an important role in communications among the Actors. This will be discussed in more detail later. Actor Condition

Data Action Event Scenario

Actor Condition Data Action Event Scenario

A2: Alarm_Sensor C2,1: Power_Is_On [Power == On], C2,2: Power_Is_Off [Power == Off], C2,3: Legal_Operation [Operation == Legal], C2,4: Illegal_Operation [Operation == Illegal] D2,1: Power [On/Off], D2,2: Operation [Legal/Illegal] Act2,1: Get_Operation_Info E2,1: User_Operation E2,2: Thief_Operation E2,3: Inform_Horn_Of_Illegal_Operation Scnr2,1 – Inform Alarm Horn of Illegal Operation: /*Event Thief_Operation comes in*/ Using ACTOR:Alarm_Sensor if (Power_Is_On) then { DATA:Alarm_Sensor.Operation = Illegal; emit EVENT:Alarm_Sensor.Inform_Horn_of_Illegal_Operation } Table 2.3: Car Sensor Specifications A3: Alarm_Horn C3,1: Power_Is_On [Power == On], C3,2: Power_Is_Off [Power == Off] D3,1: Power [On/Off] Act3,1: Beep_Once E3,1: Inform_From_Sensor_Of_Illegal_Operation Scnr3,1 – Beep Three Times on Illegal Operations: /*Event Inform_From_Sensor_Of_Illegal_Operation comes in*/ if (Power_Is_On) then { do ACTION:Alarm_Horn.Beep_Once do ACTION:Alarm_Horn.Beep_Once do ACTION:Alarm_Horn.Beep_Once

9

} Table 2.4: Alarm Horn Specifications Bottom-Up SoS Modeling The bottom-up process models the subsystems first and then uses them as building blocks. Using the same car alarm example, Table 2.3 and 2.4 will be constructed first before Table 2.2 is constructed. The key is to ensure that high-level specification can be supported by existing low-level operations.

2.3 Service-Oriented Modeling In an SOA, a computing unit is often a service, and a service can further be autonomous such as an agent [32]. This project uses an extended service specification, specifically, in addition to regular service specification such as those in WSDL, each service also specify its behaviors as scenarios in IASM and its constraints as policies as shown in Figure 2.4. Currently, many projects are also extending the regular WS specifications including those semantic Web projects such as DAML-S and OWL-S.

Service

Interfaces – Actions Scenarios – Behaviors Constraints – Policies

Figure 2.4: Service Structure As shown in Figure 2.4 one can see that each service is specified by ISC below: 1) I (Interfaces); 2) S(Scenarios); and 3) C(Constraints). Any WS client can use the ISC specification to know the behavior of the service and use it when the ISC specification meets the need of the application. The SOA extends WS by requiring each service publishing its ISC specifications in addition to its WSDL specifications. Like WS, the SOA organizes each sub-system as a service, and each sub-system interoperate with each other via standard protocols. The differences between WS and SOA is that the entire system including all of its internally layers are organized into the service architecture, rather than just at the application level like WS. In other words, the system will become inherently survivable in case of system failures because each layer of the system can be considered a loosely coupled architecture

10

with services. Furthermore, each service will be specified using the ISC convention: • Interface Specification – Input/Output parameters – Communication protocols – Interfaces with other sub-systems • Scenarios Specification – Specify the service scenarios using the ACDATE model – Specify Interactions with Other Sub-systems • Constraints Specification – Based on the scenario model and ACDATE model – Specify the properties of the services must have such as [1] • Reliability • Availability • Security • Timing • Concurrency • Performance • Sequence • Safety – These constraints must be addressed at runtime to assure dependable computing. Note that a service can be formed by composing several other services, and in this case, the overall service has its own ISC specifications, and each of its sub-services also has its own ISC specifications. This is shown in following figure:

Once the ISC specifications are available, it is possible to perform various static and dynamic analyses such as completeness analysis, consistency analysis, state analysis, pattern analysis, usage analysis, security analysis, and safety analysis either at compile time or runtime. For instance, a real-time message exchange service is a program that can forward incoming messages from and to the registered parties. It also blocks any unauthorized messages that are trying to reach to a registered party, and it prevents a classified or sensitive message from being sent to any unauthorized party. The following shows some of its ISC specifications: Interface Specification: • Register/deregister: Participants register or deregister to the service with the information of identification, address, authorization level etc, • Update registering information, • Messages receiving and forwarding.

11

Scenarios Specification: the scenarios can be used to describe a service functional behavior and non-functional constraints. One functional scenario for this service could be: Begin: While (Event: Receiving) Action: Check the Authorization levels If (Condition: Authorized) Action: Forward Message ELSE Action: Discard the Message End Constraints Specification: • Timing constraints: Message forwarding should not take more than T seconds after it receives the message at any time. This constraint is represented as: t(event. Forwarding)