Simulation is expertise driven method. It works as an semi-automated process governed by the solver and specific system characterized by mathematical formula. It is possible to combine System simulation with machine learning to allow interactive design process. To do so requires the knowledge of solving the state driven problem to be defined as patterns.
The initialization bias is such an example of a pattern that constructed and identified using machine learning.
Provided that the capability to define an existing phenomena as model is available, the natu-ral conclusion to derive from modelling is that it is in essence a linear process. However, this is inherently a faulty conclusion. Just like any natural process, modelling is both iterative and repetitive process. Reducing the dimensionality of a model is therefore, also a non-linear process. The non-non-linearity characteristic also means that simulations are inherently connected with cognitive reasoning (human in the loop). When Artificial Intelligence (see AI) is developed with cognitive reasoning, it can replace the requirement for human in the loop to provide optimal results to problems like designing for problems like the bridge en-gineering challenge. Ultimately this will change the ownership of the problem; human will no longer have the ability to contest the findings of the simulation. Without the capability to derive the logic used to gain the output, people can only choose whether to implement the solution based on output or not.
3 Service
Combining Simulation and Service bridges two scientific domains, mathematics and IT around the task of isolating the logic of the system dynamics from the environment and needed data. This can be done by isolating the logic of the system dynamics from the envi-ronment and data required to execute the simulation. From a complimenting viewpoint, the simulation (system) is required to link with service (platform) in bottom-up form. How these two constructs could work together is outlined in Figure 6.
As distributed application logic (Service) and the systems expressed as the product of math-ematical equations (Simulation), the process is based on the service encapsulating the sim-ulation. To have this capability, the service must function as the sort of life-support system for the simulation. The key capabilities to meeting this requirement are listed at the service layer (Figure 6)4.
Part of those capabilities required are covered in Chapter 2. These include the management of the state space, system input and output. The rest, including model configuration, error, and the generic quality metrics to evaluate the service, are left to be studied. The remaining capabilities are addressed in relation to the service and simulation at constructed model de-fined using RDF/OWL (see ontology) notation (Section 3.3). Utilizing the language that has predefined set of entities constituting as metamodel (MOF, section 2.4) makes the notation compatible with the MDA.
At generic level, the purpose of service is to enable high-level integration based on the de-fined system as a super-type for the continuous system to be embedded (Figure 6). To relay actions for the service to take request - response protocol is often used. The request is the trigger to force action and the pending response is the service-provider acknowledgment to close the transaction triggered. These request-response transactions are commonly executed at server-client architecture, which means that the internal logic and the (process) controlling
4. The traits (Figure 6) to evaluate the state and output are founded on the specification for AutoSimOA (Kathryn Hoad, Stewart Robinson 2011); the remaining attributes were required to be solved for the implemen-tation (Chapter 4).
Figure 6. Service and simulation at technical domain.
metrics are isolated. The specific service capability to process continuous system, therefore, inherits the super-type to process the state space driven input and output to link with the internal logic of simulation with client. This leads paradigm common to machine learning, where the output is deducted based on pattern produced by state and time (László et al. 2000, Page 4, Figure 4).
The properties associated with the IT based service paradigm are simple - the client provides input and validates the output and the server executes the commands (Figure 9). On top of this, the key issues to resolve for the generic service are:
• Security and ownership - protocol to authenticate and identify users to allow the trans-actions through the service interface;
• Error management - overloading the default process of halting code execution on error, providing parametrisation for the severity of an error, and defining user-friendly causes to known errors;
• User interface (UI) - console, html-site, or application;
• Data source access - the simulation specific location to the data produced as output or
statistics;
• Configuration - the universal settings like the solver, time, and time-step and, the local settings like the input, initial state and output;
• Status - run-time setup to initialize, run and end the specific simulation.
To interface (Figure 7) with the system that is modeled in terms of state, time, and causality, requires a process capable of handling an interchange between the service provider (server) and client. For stateless systems the de-facto architecture is SOA. The architecture simplifies the service as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description."(MacKenzie et al. 2006, Page 12). However, the architecture does not consider the (global) state in its design. Since SOA does not match with requirements for continuous system, the goal of this chapter is to map and isolate the changes needed for the conversion of SOA to state driven solutions.
Figure 7. Interfaced Service (Partridge and Bailey 2010, Page 4, Figure 1).