Complex system architecture and modularity

System architecture can be viewed as an abstract description of the entities of a system and the relationships between them [2]. It is one of the most convenient ways to define and manage complex systems. The system is defined as a set of different elements and relationships to perform a unique function which is not performable by the elements alone. The systems within the system and the components within a sub-system are interconnected or dependent on each other and these relationships define the sub-system architecture [7]. Complexity of a system is defined by the complexity of the interconnections and/or the dependencies in the system architecture [8]. Architecture therefore relates to the structure in terms of components, connections, and constraints of a product, system, process, or element. System Architecture’s logical decomposition defines a vehicle into its subsystems, the interfaces of these subsystems in terms of physical energy and logical control flows, and the interactions between the vehicle and the driver. This decomposition means that a single designer or design team can no longer manage the complete product development effort. In the context of automotive design, vehicle may be partitioned by object into body, powertrain, and suspension subsystems (see Figure 2-1) [10]. Aspect partitioning divides the system by discipline. The same automotive design could be partitioned by aspect into structural, aerodynamic, and dynamics disciplines. Focusing on the organizational level, the vehicle partitions affect also the tasks, roles and simulation models delegation between related engineering disciplines. The simulation model creation process involves a number of parallel activities in which experts in different domains create or reuse component (or atomic) level models to build up a full-vehicle system model [13]. One can think of design as a process that consists of decomposition and composition. High-level functions are hierarchically decomposed into functions for subsystems; these sub-functions are then mapped to physical components that are, in turn, recomposed into a complete system. During the process of composition (i.e. synthesis), the designer defines which components are used and how they interact with each other. The integration must pass through the proper management of its interfaces. Together these interfaces raise new system properties that no subsets of its elements have [8]. Consequently, considering and managing all interfaces in a consistent way may become complex. In particular, parameter or component couplings relating to different domains must be exhaustively identified, which is rarely possible.

46

Supporting Multidisciplinary Vehicle Modeling:

Towards an Ontology-based Knowledge Sharing in Collaborative Model Based Systems Engineering Environment

Figure 2-1 Vehicle decomposition

Distributed design teams typically handle the model at different levels of abstraction, ranging from very high-level system decompositions to very low-level detailed specification of components. This is particularly challenging for the design of multi-disciplinary systems in which components in different disciplines (e.g., mechanics, structural dynamics, hydrodynamics, heat conduction, fluid flow, transport, chemistry, or acoustics) are tightly coupled to achieve optimal system performance [12]. Moreover, the design and development of domain level simulation models is usually outsourced to different lead suppliers (or provider) to manage time-to-market and cost. Today, one of the problems in this collaborative environment is that models are usually considered as available, ready to be integrated (plug and play) or requested directly from a model provider without specifying any method. However, most of the technology or service provider’s simulation model is in a Black Box (BB) format for preserving the intellectual properties. BB models can be interacted only through the inputs and outputs of a well-defined interface (see 1-3) [14].

47

Supporting Multidisciplinary Vehicle Modeling:

Towards an Ontology-based Knowledge Sharing in Collaborative Model Based Systems Engineering Environment

2.2.1 Component and port-based modeling

A complete vehicle system model must take the response of the various physical subsystems into account, the function of the controller modules (both subsystem and vehicle level) as well as other external influences like the environment and the driver [2]. Vehicle-level attributes, such as energy, safety management and performance, to be examined and optimized for various operating scenarios. These vehicle-level attributes are tightly coupled; investigating the tradeoffs between these attributes is crucial for system design (see Figure 2-1) [6]. To create multidisciplinary vehicle model, it is necessary to first plan and develop detailed domain analysis models according to vehicle-level goals and requirements. Once these domain models have been planned, developed, verified, and validated, they can be integrated together to simulate a complete vehicle. Capability for the selection and integration of models is improved by model composability [16 and 33]. The compositional modeling paradigm distributes complexity associated with complex system modeling to individual components and facilitates reuse of high-fidelity component models, which are expensive and time consuming to obtain in general. Component-based modeling allows users to quickly and efficiently create high fidelity simulation models by linking independent model objects. Capabilities for the selection and assembly of models can be improved by engineering composability. The advantages of this approach are, however, rapidly offset by the difficulties associated with tracing the impacts of one subsystem design on another one (i.e. managing interfaces among subsystems). This phenomenon is also referred to as a

‘dependency problem’ [19]. To achieve composability of numerical models, Paredis and Diaz-Calderon [16, 17] introduced a port-based modeling paradigm which can be hierarchically defined when it consists of a composition of sub-models, resulting in a compound component. When the sub-models are also compound, multiple levels of hierarchy occur. The composability of a model facilitates to trace the impacts of one subsystem to another one, managing interfaces among subsystems. It is based on two concepts: port and interface. Ports correspond to the points where a component exchanges energy or signals with the environment. (see ^Figure 2-2a).

48

Supporting Multidisciplinary Vehicle Modeling:

Towards an Ontology-based Knowledge Sharing in Collaborative Model Based Systems Engineering Environment

Figure 2-2a Port-based design representation

There is one port for each separate interaction point, and the type of a port matches the type of energy transported. The energy flowing through a port is characterized by their across and through variable, also called effort and flow variables in Bond Graph modeling [20, 21]. According to Eppinger and Salminen [22], interactions between components can be identified along the technical dimensions of spatial, energy, materials and information. The Interface notion is also important because the interaction may include well-specified interfaces. The system interface specification identifies input and output attributes by name, data and communication type (i.e., input, output or bidirectional). The connection mechanism of model specifies the interface definition and connections. If the connection is a causally coupled relationship, it is called

49

Supporting Multidisciplinary Vehicle Modeling:

Towards an Ontology-based Knowledge Sharing in Collaborative Model Based Systems Engineering Environment

causal connection. The causal connection expresses the interface as input/output relationship in orher words; the causality determines the direction of the effort and the flow. If the connection is non-causal relationship, it is called non-causal connection (see Figure 2-2b, Chapter 6 and Appendix). The non-causal connection expresses the interface as variables shared relationship.

Figure 2-2b Port-based design representation and causality

The result of linking these models is a model architecture that can be used to evaluate the integration performance of the system as well as investigate the interactions and performance of the individual component models. Model users may be able to assemble the model component parts in a plug-in manner, thus minimizing the time, cost and expertise required to construct comprehensive models within the context of their organization [18, 19].

To be able to reuse existing component level models in a black box fashion and to integrate them to a full-vehicle system model, one needs to have a holistic view of the system [23]. This need requires integrating the system architecture into the early design process. It helps also to synchronize between actual needs of the downstream process and what the upstream process is delivering (see Figure 0-). But today, most of the high level model development and integration activities do not integrate product architecture to their model design phase. In this manner, the system level model integration activity is satisfied by finding, modifying and integrating of the existing model without knowing which sub models are meaningful to connect together and how they can be connected to each other and which the interfaces are.

Thus, the approach that we propose provides the system architecture integration in early model building process. System architecture integration facilitates also model plug-in (i.e., model integration phase) activity by providing a holistic sub model integration schema with its interface connections. To make sure that a multidisciplinary model is developed and performed according to customer requirements (i.e., model user), one needs to follow a precise design methodology that we introduce in Chapter 4 and 5.

50

Supporting Multidisciplinary Vehicle Modeling:

Towards an Ontology-based Knowledge Sharing in Collaborative Model Based Systems Engineering Environment