Complex systems traditionally involve partners from di erent companies with their own domains of expertise. During design stages, these partners need to exchange pieces of information and to debate around architectural and implementation choices. Model Driven Engineering for System Engineering simpli es system knowledge sharing, while simulation provides sound results to drive debate. As a consequence, gaining a exible and dynamic tool that models and simulates the architecture is highly valuable. In this paper we focus on the functional architecture design and analysis steps of the system engineering process. We identify adaptation to existing system engineering process, tool modularity and interaction with models as three grounding principles for a exible system model simulation tool. We show that meta-modeling and layered architecture for a simulator are enabling technologies for our three principles. We also demonstrate the use of these technologies by implementing a simulation tool in the context of a sea- oor observatory project.
System engineering is an interdisciplinary activity during which experts from
several domains having an holistic approach look for the near optimal system
design to answer to a client's needs [
In this paper, we describe three principles that ground a exible simulation tool: { Adaptation to system engineering processes (current, and emergent/future); { Extensibility of the tooling; { Interaction with models.
Companies have already de ned their system engineering process and use tools to support the process. Our approach is based on the respect of what has already been done in the companies. Multiple domains such as mechanics or software are involved in the design of a system. It is not possible to create a tool taking natively into account all of these domains. Domain experts should be able to add new functionality to the tool and remove those which are not required. Models are prototypes. Domain experts are using them to debate over the design alternatives for the system. They should be able to modify the models according to the result of their discussion. To realize our three principles, we describe a meta-model de ning the concepts of a functional architecture. A functional architecture is the de nition of the functions implemented in the system, their interactions and their structural layout. The meta-model describes the structure, the communication and the behavior aspects of functions that should be implemented by the system. In a Model-Based System Engineering approach the meta-model ensures independence from existing modeling tools. To obtain a exible simulation tool, we de ne a layered and component-based architecture. Layers group tool functionalities according to their degree of speci city to a domain of expertise. Components isolate functionalities and provide a convenient way to reuse them.
The rest of the paper is organized as follows. Section 2 describes some related work. Section 3 rst provides a motivating example for this work coming from a sea- oor observatory project we were involved in. Section 4 provides a description of the grounding principles. Section 5 describes the technologies usable to implement a exible simulation tool. 2
Di erent formalisms can be used to model a system functional architecture such
as Enhanced Functional Flow Block Diagram (EFFBD) and SysML models.
EFFBDs are an extension of Functional Flow Blocks Diagrams. Functional Flow
Blocks Diagrams de ne functions and their sequence of execution. EFFBD adds
data ow to the functional architecture modeling [
On the opposite, Karsai and al in [
The MeDON [
During the design phase of the MeDON project, experts from electronic, software and electronic elds among others were involved. Experts worked in their speci c eld of expertise and had interactions together only during progress study meetings each six month. There was no knowledge repository to store a common view of the observatory design. Decisions impacting every elds of expertise were made according to eld speci c goals without coordination with other experts. Some of these decisions had huge impacts on work already done. For example, a deployment site was chosen at the beginning of the project. However, this choice had to be modi ed due to energy supply shortage. This choice was necessary but it implied rework on the deployment of the data computing softwares and on the choice of the servers. With a functional architecture independent from any technology, it would have been possible to reuse a lot of engineering work. Besides, a better communication between experts about the possibility of power supply shortage would have led to the de nition of at least two alternatives architectures. So, when the change occurred, the switch of architecture would have been anticipated.
The MeDON project is now being upgraded to include the localization of the
sound sources. Learning from our experience, we decide to use a SysML-based
system architecture model to de ne the system architecture and to have a shared
view on the system. An algorithm based on the di erence of sound arrival time
between each hydrophone has been selected to locate sound sources. The sound
is acquired by at least three hydrophones in a two dimensional approximation of
space. One of the hydrophones is chosen as reference. Each hydrophone acquire
sound signals. The acquired sound is then analyzed to detect the presence of
a signal higher than the noise. If one is found it is considered as a detection.
For each detection on each hydrophone a di erence is made between the time of
reception on the hydrophone and on the reference. It is then possible to have a
location of the sound source [
In this section, we will introduce three principles underlying the development of our simulation tool. First, we know that industrial companies have well de ned system engineering processes. So we think that our tool has to adapt to these processes and not the other way round. Second, we think that the users' needs will continuously evolve so the simulation tool must follow these evolutions. As a consequence, the simulation tool must be extensible. Third, we would like that the model and the simulation become an active support for re ections. This leads to interactions with models. 4.1
The ISO 15288 standard [
Simulation relies on the modeling activity. Models de ne the abstraction level of
the simulation and serve as entry point. A model driven approach for simulation
is made of four steps [
In our case, the functional architecture can already be modeled using languages
such as SysML [
Complex system design requires work from experts coming from multiple domains. Each expert has its own view on the system through its domain vocabulary and also on the metrics given by the simulation. The simulation tool must be able to take into account the di erences between domains. Experts need a tool adjusted to the current situation they are facing. Experts should be able to add new functionalities to the simulation tool and remove the ones they are not using.
This requires a modular approach like the one used in the Linux Kernel. The Linux kernel is made of a set of modules. Each module has an unique purpose such as handling a USB device or printing. A module can be loaded and unloaded. However, some modules are essential to the stability of the system and they can not be unloaded.
Like the Linux kernel, the simulation tool should be made of modules that can be loaded and unloaded by domain experts as required by their current task. Besides, a distinction between modules should be made. Some modules are at the basis of the simulation and so should not be unloaded. Other modules deal with domain speci c activities and may be loaded and unloaded at will.
Interaction with models consists in observing the simulation and its results and in modifying the simulated model. These activities serve the purpose of: { Enabling to de ne new alternatives of functional architecture by debating; { Simulating the di erent alternatives; { Comparing the results of the simulation.
One of the goal of functional architecture is to de ne groupings of functions. In the simulated models the functions groups should be modi able to perform tests on di erent alternatives. A function can be seen as an assembly of basic operations. The order in which the basic operations are performed or their nature should be modi able. Those interactions with models are risky: deadlocks can be created by the modi cations. Furthermore, modi cations may cause a loss of coherency between the simulated model and the simulation results. The simulation results must be linked to the simulated model. So the simulation engine must take into account all the modi cations performed on the model so that the simulation results are still valid.
Tests on the structure of the model should be performed to avoid these risks. At runtime, a deadlock check should also occur. The modeled elements themselves should also provide pieces of information about which modi cations users are allowed to perform on them. Unauthorized modi cations should be blocked by the model elements. 5
In this section, we will introduce the technologies used to implement the three principles. Meta-modeling and model transformation implements the adaptation to system engineering process. Layered architecture helps to implement tool extensibility. 5.1
We de ned a meta-model describing functional architecture models. This
metamodel shown Figure 3 is based on the function description in [
The functional structure is described by a Composite pattern between the FunctionComponent, LeafFunction and LogicalFunctionGroup meta-classes. The metaclass LeafFunction describes the basic functions of the system. A logical function group (LFG) can be made of other LFGs and of basic functions. in the example of our sea- oor observatory, we have a LFG called Acquisition that groups two LeafFunctions RawAcquisition and Detection. The two latter are LeafFunctions as they are not further broken down.
Basic functions can communicate through communication links. Each communication link has a behavior to de ne if the communication will be synchronous or asynchronous. To bring exibility in modeling the behavior of functions, we rei ed the concept of communication link. We decouple the behavior of the communication from the behavior of the function. Changes in the function behavior will not a ect the way communications are performed. LeafFunctions know each link through an alias. There is one link per exchange between two functions. This mechanism is similar to ports in a component-based modeling. Unlike ports, our modeling of links do not allow broadcast. However, it eases the analyses of the exchanges between functions as exchanges between a sender and multiple receivers must be explicitly modeled.
The behavior of a function can be described as a sequential list of basic operations such as sending or receiving data and performing a computation. The sending operation is described by the name of the communication link on which the data are sent. The receiving operation is described by the name of the communication link from which the data are read. The computation operation is described by the computation duration.
To adapt ourselves to the process and tools used in the industry, the meta-model de ne an intermediate representation of functional architecture. The functional architecture is modeled using companies' internal modeling tool. Model transformations extract the data relevant to functional architecture from companies' model and create a new model compliant with our meta-model. This new model is used to de ne the simulation to perform independently from the companies tools used for modeling the functional architecture at the beginning. Our meta-model was designed in the context of the sea oor observatory example and uses vocabulary of data processing such as Computation. However, it can be easily extended to suit more generic needs. An Action meta-class can be created. The Computation meta-class will inherit from it. The class CommunicationBehavior can be renamed in LinkBehavior. Classes detailing the behavior of ows inheriting from LinkBehavior can be created. 5.2
To obtain tool extensibility we rely on a layered architecture each layer being made of software components. In a layered architecture each layer uses services from the lower level layer and provides services to the upper level one. It is then possible to build a new service providing business oriented data built from tool services. Components have a well-de ned interface. Their functional responsibilities are clearly identi ed. It is possible to switch two components with the same data inputs and outputs. Components may also have the ability to be loaded at runtime. New functionalities can then be added to the tool at runtime. Using a layered and component-based architecture has several advantages. First, using component enable to co-locate pieces of code having the same role. When a modi cation is required, locating the area in the code that must be modi ed is easy. Second, using layers and components requires to clearly identify the interfaces between the components. This enables to write new components and integrate them in the simulator. The only condition is to comply with the interfaces. However, using layers and components for the architecture have some disadvantages. The complexity of the architecture of the simulator may be increased. Information useful in a component may follow a complex path before gaining the targeted component.
We decompose the simulation tool into three layers as shown Figure 4. The Core
Sequence Diagram Model Importer Generator
Simulation Engine Concepts layer contains the simulation engine component. This component contains the implementation of the meta-model.
The functional architecture is modeled outside our simulation tool and model transformations are performed to import it in our tool. A model importer component should be responsible for performing the model transformation. Besides, the simulation should generate output rendered into an user friendly format. An export module per output format should be implemented. All those components are located into the Input/Output Tools layer on top of the Core Concepts layer. The Company Speci c Tools layer will contain the di erent components developed speci cally for the users' needs. For example, a component may be written to compute the global waiting time the di erent functions and display the obtained value.
An example of component decomposition is the integration of a sequence diagram utilities. Sequence diagrams enable to visualize message exchanges between functions. We de ned two components: one that displays directly a sequence diagram and one which creates a log le using a format readable by an external tool in such as the sdedit tool3. A component approach is well suited because in both case information about the message exchanges are the same i.e. the identity of the sender, the message name, and the identity of the receiver. Besides, the behaviors of both component are really di erent, the rst manage a display and the second one write data in a le. The link between the execution engine and the components is made through an interface detailing the data structure exchanged between simulator components. 6
In this paper we presented the three necessary principles to obtain a exible simulation tool at the functional level. First, we think that such a tool should adapt to the system engineering processes already in use in companies and not modify it. Second, we advocate for a tooling able to be adapted to speci c needs. Third, the simulation tool must enable to play with the models simulated. We also gave a list of enabling technologies. Meta-modeling and model transformations may support the adaptation to existing system engineering process. Flexibility is achieved through the independence from deployed tooling. Module-based tooling enable the adaptation of the tool to the user needs. Flexibility is achieved by the ability to load and unload modules at will according to the project environment. A future work is to extend our functional architecture metamodel. We want to reify the composition link between the LogicalFunctionsGroup and the FunctionComponent metaclasses. It will then be possible to add pieces of information to specify the link such as an alternative identi er. This identi er will ease the process of implementing, simulating and comparing functional architecture alternatives.
This work has been done with the nancial support of the French Delegation Generale de l'Armement and of the Region Bretagne. 3 http://sdedit.sourceforge.net/ The authors also wish to thank Zoe Drey and Ciprian Teodorov for their valuable input to this paper.