To bridge the gap between the client and the provider the server-client architecture is com-monly used. In principle, a service transaction is formed between two distinct programs that share data through an interface linked with the information model. In this section, the focus is on the information model required to connecting the state-driven system within the service (Figure 6) and to identify the distinct process for the information model to work using the UML sequence diagram (Figure 9).
The information model is divided into three fragments (client, server, and interface). To meet the requirements for the process (Figure 6), three namespaces (ontologies) are defined to log
Figure 9. UML Sequence diagram to running simulations encapsulated inside a service.
and identify client communication with the service provider, to operate selected the simula-tion, and to manage the interface (Figure 9). Together the namespaces form the information model to describe the relations between the system (simulation) and the service6:
• Client to service connection - class and object entities (Tables 5, 6) and connections at graph (Figure 10);
• Server to simulation connection - class and object entities (Tables 7, 8) and connections at graph (Figure 11); and
• interface - object entities (Table 9 and connections at graph (Figure 12).
6. Each ontology has two tables and graph to describe the available classes, objects, and relations.
Table 5. Class entities for service ontology
Domain Rule Range
Configuration vThing Class
ErrorTypes vThing Class
SimulationProperty vThing Class
Input vSimulationProperty Class Output vSimulationProperty Class SimulationTime vSimulationProperty Class Source vSimulationProperty Class State vSimulationProperty Class
Owner vThing Class
Service vThing Class
Simulation vThing Class
SolverType vThing Class
Solver vSolverType Class
v: definitive type "object"
>: the super type - "inherited | abstract"
∃ : existential quantification - "there exists"
∀ : universal quantification - "for all"
The information model covers the properties needed to encapsulate the simulation inside a service. The RDF/OWL notation allows global service discovery and shared semantics, which is based on the object-oriented paradigm with entities identified by the uniform re-source identifier (URI) (Gessler et al. 2009, Page 4). The entities are assigned with a type of class, instance, object property or data property with the following guidelines:
• Instance is defined by class,
• Data is connected to class,
• Object is the relation between two classes, and
• Class is defined by the super class (Thing).
Table 6. Object entities for service ontology
Object domain range
hasConfiguration ∃ThingvSimulation > v ∀Configuration hasErrorStatus ∃ThingvSimulation > v ∀ErrorTypes
hasService ∃ThingvOwner > v ∀Service hasSimulation ∃ThingvService > v ∀Service
hasSolver ∃ThingvConfiguration > v ∀SolverType
hasProperty ∃ThingvSimulation
-hasInput vhasProperty > v ∀Input
hasOutput vhasProperty > v ∀Output
hasSimulationTime vhasProperty > v ∀SimulationTime
hasSource vhasProperty > v ∀Source
hasState vhasProperty > v ∀State
The hierarchical design is achieved with statements comprised of the subject, predicate, and object. To create alignment with the specific domain, the entities have to be created, named and connected using a finite number of statements. The symbols used in the tables are based on the OWL description logic; a subset to the native first-order logic (predictive logic) notation (Wikipedia 2014b). The use of information model is motivated by the capability to form interactions based on the publicly shared medium, which shifts from (complex) static interactions to (simple) dynamic interactions. This means that the variables required to fill requests are defined at run-time, and thus, can be stored globally. The capability for the global registry for state-driven systems also allows the transactions between the client and the provider to utilize the outcome of the previous iterations made. Concerning the defined service architecture (Figure 9), the basic operation can be summarized with three steps;
• The request to search simulation(s) - the request is processed at the server side to produce a list of available simulation based on the criteria defined;
• The request to execute specific simulation - the server initiates the simulation platform, with settings required for the initial state, input and solver details; and
• After completing the request for simulation run, the response contains the run-time
Figure 10. View describing the service as an ontology graph.
statistics, occurred errors, and sources for the simulation output.
The generic role for the service is to view the simulation as a specialized process. Since the simulations are more complex fragments of application logic than the conventional (stateless) applications, The process to govern the simulations requires additional tasks to be defined (Table 2). For instance, the extended capabilities required to serve the simulations include settings to configure the solver, action on error, initial input, state, output, and time manage-ment. The object properties for the specific service are:
• hasConfiguration - allows for the simulation generic options like solver to be defined.
• hasErrorStatus - allows for the error classification to generic and simulation specific instances.
• hasInput - allows the user provided values for specific input-signal to be recorded.
• hasOutput - allows the outcome to specific output-signal be recorded.
• hasService - allows the owner affiliated with specific service to be identified.
• hasSimulation - allows the service to be linked with one or more simulations.
• hasSolver - classified as a generic configuration, the solver type and name correlation
Table 7. Class entities for simulation ontology
• hasSource - allows the service to access the library or executable needed to run the simulation selected for execution.
• hasState - allows external definitions to be made to facilitate for initial state, to store the values for final state.
The connections in the distributed information model reflect the practical experiences of working with the simulation platforms. The model as a reference to general alignment with the mathematical theory of the continuous system (Figure 6). The simulation namespace is primarily designed to allow the linked documentation of relations between the variables,
pro-Table 8. Object entities for simulation ontology
Object domain range
hasBuild ∃ThingvMain > v ∀Build
hasConfiguration ∃ThingvMain > v ∀Configuration hasDataProperties ∃ThingvModel > v ∀DataProperties
hasState ∃ThingvModel > v ∀State
hasDifferentialEquations ∃ThingvModel > v ∀DifferentialEquations
hasError ∃ThingvMain > v ∀Error
hasExternal ∃ThingvDataProperties > v ∀External hasOutput ∃ThingvDataProperties > v ∀ExternalOutputSignal
hasInput ∃ThingvDataProperties > v ∀ExternalInputSignal
hasLibraries ∃ThingvMain > v ∀Libraries
hasFunction ∃ThingvMain > v ∀FunctionType
hasContinuosDerivative ∃ThingvMain > v ∀ContinuousDerivatives hasOutput ∃ThingvMain > v ∀hasOutput Output hasInitialization ∃ThingvMain > v ∀Initialization hasUserDefined ∃ThingvMain > v ∀UserDefined
cess, data, model-logic (equations), and the run-time configuration. The possible interactions describing the object properties for the specific simulation are:
• hasBuild - allows the capability to add run-time parameters for simulations to execute.
• hasConfiguration - allows the simulation specific configuration to be defined.
• hasDataProperties - allows the simulation specific variables to be defined for the math-ematical model governing the simulation.
• hasDifferentialEquations - allows the listing of equations controlling the state and re-lations between variables defined.
• hasError - allows the user-defined and generic errors to log events during the simula-tion run.
• hasLibraries - allows the definition for the external libraries prior to simulation run.
• hasFunction - abstract property for functions available for documentation.
Figure 11. View describing the simulation as an ontology graph.
• hasOutput - allows the definitions for output at individual time-steps taken during the simulation run.
• hasContinuosDerivative - allows the definitions to calculate the next state during the simulation run.
• hasInitialization - allows the definitions for external call-back functions prior, during or after the simulation run.
• hasUserDefined - allows the definitions for custom functions during the simulation run.
• hasExternal - abstract property for variables visible to users.
• hasInput - allows for the input variables to be shared through service.
• hasOutput - allows for the output variables to be shared through service.
Since the concept of service is based on relative independence of assignments based on causality driven by events, an internal mechanism is needed to keep track on the pending and performed actions (Table 2). The second aspect to messaging is to facilitate clients to communicate with the server-side components based on the user assigned goals. The current industry-standard for the request - response based communication is an XML data-stream object (XML/XMI) (Siegel 2014, Page 6). The XML data-stream object is usually based on
Table 9. Shared object entities for the interface ontology
Object domain range
hasRequestForInput ∃ :*vRequest > v ∀ :ServicevInput hasRequestForOutput ∃ :*vRequest > v ∀ :ServicevOutput hasRequestForSource ∃ :*vRequest > v ∀ :ServicevSource hasResponseForService ∃ :*vResponse > v ∀ :Service -vService
hasExternalError ∃ :ServicevErrorTypes > v ∀ :Simulation - Error
hasExternalInput ∃ :ServicevInput > v ∀ :Simulation - ExternalInputSignals hasExternalOutput ∃ :ServicevOutput > v ∀ :Simulation - ExternalOutputSignals hasExternalSource ∃ :ServicevSource > v ∀:Simulation - Main
the predefined schema. For instance, the object cam contain the original request and how it was handled. The collective view describing the relations between the service and simulation ontology combined to a single graph (Figure 13).
The benefit of using the RDF/OWL notation is that it can accommodate the URI, and thus, facilitate the global service discovery process. The prospect of the global discovery process means that any public domain can be transformed to double as a gateway to utilize (serve) the server-side components. The other benefits to RDF/OWL are that it is an open standard facilitated by the world wide web consortium (W3C), rule-based and able to utilize the open world assumption. To access the previously defined namespaces requires specific header and import settings to be made (Listing 3.1):
Listing 3.1. OWL headers
@ p r e f i x : < h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl #> .
@ p r e f i x owl : < h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl #> .
@ p r e f i x r d f : < h t t p : / / www. w3 . o r g / 1 9 9 9 / 0 2 / 2 2−r d f−s y n t a x−n s #> .
@ p r e f i x xml : < h t t p : / / www. w3 . o r g /XML/ 1 9 9 8 / n a m e s p a c e > .
@ p r e f i x x s d : < h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#> .
@ p r e f i x r d f s : < h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / r d f−schema #> .
@base < h t t p : / / www. s e m a n t i c w e b . o r g / 2 0 1 5 /
< h t t p : / / www. s e m a n t i c w e b . o r g / 2 0 1 5 / s e r v i c e _ i n t e r f a c e >
r d f : t y p e : O n t o l o g y ;
: i m p o r t s < h t t p : / / www. s e m a n t i c w e b . o r g / 2 0 1 5 / s e r v i c e > ,
< h t t p : / / www. s e m a n t i c w e b . o r g / 2 0 1 5 / s i m u l a t i o n > .
Figure 12. Collective view describing the relations between the service and simulation on-tology combined at single graph.
Together these commands access the resources needed to define the RDF/OWL template.
The remaining definitions are an interface for mandatory communication between the two existing namespaces and the connections to allow for the requests to be submitted and re-sponses to be returned. The benefit of this arrangement is that the ontology can grow in-dependently as long as the defined object relation are kept intact. The possible interactions designed to link the client and server-side components are:
• hasRequestForInput - allows the requested input to be matched with the possible sim-ulations containing the specified signal.
• hasRequestForOutput - allows the requested output to be matched with the possible simulations containing the specified signal.
• hasRequestForSource - allows the requested simulation to be matched by name.
• hasResponseForService - allows the return response to link with the owner and the request through the service.
• hasExternalError - allows the possible errors occurred during the simulation run to be shared with the user.
• hasExternalInput - allows the populated inputs to be shared with the user.
• hasExternalOutput - allows the populated outputs to be shared with the user.
• hasExternalSource - allows the access to the simulation selected for execution.
The final stage to using the information model to facilitate the service, is the construction process for the dynamic variables replicated during the run-time. The variables, defined as instances (Figure 13), correspond to the information during the request-response chains always forming a linked set of information. The RDF/OWL notation is used here for these characteristics embedded.
Figure 13. Collective view describing instances for request - response chain as graph.
The request - response process is designed to formulate the IT specific challenges
encoun-tered during the service interface design stage for the integration between two distinct plat-forms (client and server). The general service characteristics are designed to toggle three distinct challenges related to automating or distribution logic through the service interface (Gessler et al. 2009):
• "Fatal mutability of traditional interfaces" - changing the input required for the process to function becomes an issue.
• "Rigidity and fragility of static subsumption hierarchies" - making changes becomes an issue due to the built-in complexity of the system.
• "Confounding content, structure, and presentation" - Changing the output become an issue.
These three issues affect services more than the basic stand alone application, because the service implementation have more complexity. For this project, we tried to mitigate these issues by defining a global namespace for the input, output, and state. These requirements are characteristic to servicing the continuous system (Figure 6). To submit the request for response to run specific simulation would require the following settings to be made:
• request
– Simulation name as ID;
– Time management - run-time, time-step;
– Input, initial state, and output source; and – Solver details.
• response
– Simulation name as ID;
– Variable name, usage as input or output, and conservation laws;
– Main equations linked with boundary and initialization conditions and constraints;
and
– Error(s) by ID and type.
3.4 Chapter Summary
The starting point for this chapter is a paradox - the default architecture to service stateless application is SOA and for state-driven applications the architecture with similar status is HLA. But because the HLA is heavy and designed for large organizations, it requires running the simulations at the predefined sandbox. Thus, the otherwise useful architecture is filled with problematic constraints. To combine the service with simulation, the role reserved for the service is to act as the mediator between the simulation and (interface) the external application (agents) or people.
One of the natural conclusions to make is that SOA is not enough to encapsulate a simulation as a service. The view can also derived from the other research focused on the same issue (Dragoicea et al. 2012) and (Gu, Lo, and Yang 2007). Still, SOA is widely considered as the architecture to start developing the service encapsulation to simulations.
Overall, the literature identified three technical reasons to implement the service as a back-bone for running simulations. The capabilities are: to produce estimates from existing runs by applying data-mining techniques; to determine whether the simulation was able to es-tablish an equilibrium state after initialization bias; and to integrate multiple simulations together. By default, all of these ideas can be achieved by using a single solution. Funda-mentally, the idea is that the process running the simulation has a higher level call function able to run it and to receive diagnostics data while doing so.
4 Implementation
The goal of this chapter is to portray the CFB-model state space integration with APROS.
The steps leading to this chapter are introduction and theory (Figure 1 - steps 1 and 2). The method to study the implementation as an artifact are defined by six steps leading to the capability to implement and evaluate the the CFB-model integration (Figure 1):
• Identify problem Motivate - leads to - Interference(s) with the goal to define the ob-jective(s);
• Define objectives of a solution - leads to - theory about the best possible solution;
• Design Development - leads to - Know how and practical experience;
• Demonstration - leads to - Metrics, Analytics, Knowledge;
• Evaluate - leads to - Disciplinary knowledge; and
• Communication - is the - target.
The build process for artifact has eight fragments, visualized in Table 10. Together they contains a vision for sub-processes of the artifact based development (Shirley and David 2007, Page 322, Table 2). These processes are also pursued within the scope of this research (Table 10).
The natural conclusion to derive from the building process related with the methodology of design as an artifact, is that it requires interdisciplinary communication capabilities from the research team (Shirley and David 2007, Page 327). To manage this communication, some form of documentation or specification is usually required. Whether its visual or literal, formal or unstructured, the purpose of communication is to work as a contract between the people responsible for implementation and evaluation processes.
The traditional specifications are thought out as if they need to cover everything, be lit-eral, systematic, formal, and structured. To take one example to illustrate many, the service oriented architecture modelling language (SOAML) specification is an excellent example to illustrate the trend (OMG 2012). The process of documentation is approached through method of confrontation supported by IT domain project management methodologies, such like UML. With regards to specification, the characteristics used in live projects are listed
Table 10. IT inspired build process for an artifact (Shirley and David 2007, Page 25).
Task Purpose Segment
Purpose and Scope
What is the system for, the set of meta-requirements or goals that specifies the type.
Chapter 1.
Construct A definition of the entities of interest in the theory.
Artifact mutability The changes in state of the artifact an-ticipated in the theory.
Defined by the infor-mation model (Section 3.3).
Testable propositions Truth statements about the design the-ory.
Justificatory knowledge
The underlying knowledge or theory from the natural or social science that gives a basis for the design.
imple-menting the theory. Visualized in Figure 1.
Expository instantia-tion
A physical implementation of the arti-fact that can assist in representing the theory for the purpose of testing.
Section 4.1.
below:
• Visual over literal,
• Quality over quantity,
• Details over generics, and
• Derived over inferred.
IT development projects are commonly associated with an executable solution, framework, and source development kit (SDK). In these projects software is gradually being built more on hybrid platforms allowing both contextual and method based techniques to be used in the process of building the application. In this project, the hybrid platforms included Mat-lab/Simulink, C, and APROS. The main steps to implementation is divided to two segments - demonstration and evaluation (Peffers et al. 2007, Page 55-56):
Demonstrate:
Demonstrate the use of the artifact with one or more instances of problems.
This could involve its use in experimentations, simulation, case study, proof, or other know activity. Demonstrating the artifact requires extensive knowledge of its functionality. (Peffers et al. 2007, Page 55)
Evaluation:
Observe and measure how well the artifact supports a solution to the known problems. This activity involves comparing the objectives of a solution to actual observed results from the use in artifact in demonstration. It requires the knowl-edge of relevant metrics and analysis techniques. Depending on the venue and the artifact, the evaluation could take many forms. These evaluation techniques include comparison between initial objectives with the archived functionality and quantitative approaches to the artifact performance. These quantitative mea-surements can include budget, used time, system performance comparison and time of availability. Conceptually such evaluation could include any appropriate empirical evidence or logical proof. (Peffers et al. 2007, Page 56)
To make the transition from a mathematical model to implementation requires a specific
platform. To combine the presented theory with an artifact, the purpose of this chapter is to collect the design principles of building the capability for simulations to function encapsu-lated within a service. In this context, the service is like an interface enabling two simulation platforms to work the same model. The appropriate theory to achieve the solution is to trans-form the existing simulation to function as an independent unit and to dynamically execute the transformation process for a specific platform.