Concurrent Design of Railway Vehicles by Simulation Model Reuse

This paper describes a concurrent design approach to railway vehicle design. Current railway vehicles use many different concepts that are combined into the final design concept. The design support for such systems is based on reusing components from previous design cases. The key part of the railway vehicle design concept is its simulation model. Therefore the support is based on support for reuse of previous simulation models. The simulation models of different railway component concepts are stored using the methodology from the EU CLOCKWORK project. The new concept usually combines stored components.


Introduction
Engineering design of various products can be divided into two main groups.The first one is characterized as configurational design, and can be fully described by a design network.Using such a design network, effective computer support systems can be developed.Such a computer support system, called COLIN, was developed for automotive design, together with further extensions, described in [1].
Although the railway vehicle design process is mostly a configurational one, it is not possible to establish a sequence or network of repeatable steps and operations which fully describe previous design cases.Usually, previous designs or parts of them are utilized.Current advances in computer hardware and software technologies allow designers to base vehicle design on a simulation model of such a vehicle.Thus, a significant part of the design process is the creation and verification of the dynamic simulation model of the vehicle, and experiments with this model.Further, previous simulation models and parts of them are often used.Knowledge support for such a design process is supported by the methodology and tools developed within the EU CLOCKWORK project (Creating Learning Organisations with Contextualised Knowledge-Rich Work Artifacts).
The design methodology based on multidisciplinary virtual modelling and subsequent simulation is essential for any present-day engineering design [3], and specifically for the design of complex mechatronic machines [4].In additions current engineering design is multidisciplinary and therefore based on team work.The team work often uses the potential and benefits of geographic distribution and internet communication.Engineering design draws heavily on previous experience and therefore it is essential to build and maintain the archives of previous cases.Due to the nature of the described methodology, simulation models are an essential part of this.
Engineering design is a knowledge-intensive activity, but analysing the resulting documentation of such activities shows that most of this knowledge is tacit, and is not stored for future reuse.The CLOCKWORK methodology and tools provide a means for storing, retrieving, reusing, sharing and communicating such knowledge.
This paper deals with implementation of the CLOCK-WORK methodology and tools which support integrated design of railway vehicles.

Knowledge life cycle of virtual modelling and simulation
The development of a virtual model and then its simulation typically goes through a number of tasks ( [2]).These tasks are illustrated in Fig. 1.The light arrows represent mappings between the different elements, and the black arrows represent transformation processes between the tasks.The development of a simulation, as shown in Fig. 1, involves five steps.
The first step is an analysis of the real world, since when we start to develop a simulation there exists some real world object.This real world object is investigated within a certain experimental frame concentrated on the relevant behaviour in order to answer some question, the objective of object investigation.It forms the real world system (either actual or hypothesised).From this real world system we want to create a model to use for answering a modelling question (question), such as how a real-world system would respond to particular stimuli.The real world task has three elements: the real world system, the question (modelling question), and finally the solution.
l The real world system (either actual or hypothesised), of which we want to create a model to use for answering a modelling question, such as how a real-world system would respond to particular stimuli.
l The question (modelling question) is a question -modelling objective that is based within the real world and is to be answered using simulation.
l The solution is the interpretation of the interpreted output of the simulation task.This will be left blank until there is a set of results.
The second step is the conceptual task, where the conceptual model is developed.The transformation from the real world into the conceptual world consists of creating a hierarchical break-down of the real world system being investigated (e.g., a hierarchical description of real product components and their environment).This scheme should be accompanied by a description of the function (physical interaction), as it forms the basis of the causal and functional explanation.As soon as this description is com-pleted the conceptualisation is completed.Certainly various assumptions are raised about the granularity of the modelling being provided.It is the way of "thinking about" and representing the real world system in a conceptual manner.A crucial design decision is the determination of what factors influence the system behaviour and what system behaviours are to be incorporated into this task.The result of the conceptualisation is a conceptual model investigated within the modelling environment in order to answer the modelling objective.
l The conceptual model is an abstracted view of the real world system.
l The modelling objective is to conceptualise the question and form objectives for the simulation task (i.e.what behaviour we are interested in? and how we will know that we have the correct answer from the results?).
l The modelling environment is the conceptualisation of the inputs of the real world systems, providing a simulation environment to work within in the simulation task.Typically the inputs are specified here.
Validation is the process of determining whether the conceptual model is an adequately accurate representation of the real world task.
The next task is physical modelling.The third step is the transformation from the conceptual world into the physical world.This consists of replacing of each element on the conceptual level by a corresponding element on the physical level.The elements of the physical model are the so-called ideal modelling elements (e.g.rigid body, ideally flexible body, ideal gas, ideal incompressible fluid, ideal capacitor, etc.).Again, as soon as this replacement is completed the physical modelling is completed.This is where most of the modelling assumptions are raised, and where many modelling modifications are made.This is the way of "modelling it" and representing the real world system in a physical modelling manner.For example two typical modifications are provided: EITHER an element is decomposed into more elements (a small subsystem) (e.g. a body cannot be treated as rigid body and it is modelled as a flexible body being modelled as a subsystem) OR several elements are replaced by one element as the detailed treatment of interactions is neglected.The modelling task results in the physical model, its input and the investigated output.
l The physical model is an accurate physical view of the conceptual model.
l The model input is the modelling conceptualisation of the inputs of the real world systems, providing a physical modelling of the real world stimuli to the investigated system, i.e. a detailed physical description of the modelling environment from the conceptual task.
l The model output is the modelling conceptualisation of the objectives for the simulation task (i.e.how the relevant behaviour is measured and evaluated).
Verification is the process of determining whether the physical model is an adequately accurate representation of the conceptual model.
The results of the modelling task are implemented in the form of a computer-executable set of instructions known as the simulation model.This is the transformation from the physical world into the simulation world.It consists of replacing of each element on the physical modelling level by the corresponding element on the simulation level.Usually this replacement can be straightforward, as simulation packages attempt directly to contain the ideal objects of physical models.However, some modifications are always necessary.The simulation task consists of two stages.The first stage deals with the implementation of the physical model using a particular simulation environment (simulation language and simulation software).The second stage deals with the simulation experiment, i.e., proper usage of the developed simulation model for the solution of the real world problem.Testing is the process of determining whether the implemented version of the model is an accurate representation of the physical model.
There are many relations between the models from different worlds.The main relations are connected with the The relation "is modelled as" from the conceptual world to the modelling world and the relation "is implemented as" from the modelling world to the simulation world, and finally the relation "is simulated by" and "is answered by" from real world to the simulation world.The development of objects of these relations is accompanied by many iterations (Fig. 2).

Knowledge support for virtual modelling and simulation
The above described process of creating virtual models and simulation experiments with them is accompanied by supporting knowledge that is vital for knowledge sharing and reuse within the design team.It is believed that the support-ing knowledge for the modelling and simulation process comes in two forms, informal and formal knowledge.Informal knowledge is typically concerned with relationships and knowledge about models using natural language.Formal knowledge is also concerned with the establishment and representation of knowledge about the model, but this knowledge is typically more structured, using knowledge modelling technology.Both of these types of knowledge will be associated with each world object, as shown in Fig. 3.
Based on the methodology of the Enrich project [3], the modelling and simulation objects are working documents of the engineering activity, and informal knowledge can be captured by annotations and the formal knowledge by semantic indexing, using concepts from related ontologies (Fig. 4).
Each world model is associated with informal and formal knowledge on the level of model components as well on the level of complete models.In adition, each transition between worlds is also associated with informal and formal knowledge.Informal knowledge about world object components and a complete world object describes the function, behaviour and any other useful information about the component or object in question.Formal knowledge represents the most valuable informal knowledge in terms of corresponding ontologies (Fig. 4).Informal knowledge of world transitions describes the structural changes of the model with related assumptions raised during particular a transformation, and formal knowledge of these transitions describes the relationships among the modelling processes.
The particular relationships between world models and their components can also be generalized into more abstract knowledge about the development of virtual models and their simulation (Fig. 5) The above described analysis has shown that the process of modelling can be described on the level of each world/object by three descriptors: 1.A conceptual/physical/simulation model depending on the world (CWO/MWO/SWO).2.An annotation text (informal knowledge).

Semantic indices (formal knowledge).
Similarly, each component of the model can be described by the same triplet.Capture, retrieval and search of this knowledge is supported by several tools.
It is considered that models on various levels of the framework (from various worlds) consist of components which have a specific meaning and a lot of knowledge is related to the particular model component, as shown in the Fig. 6 (e.g.how the stiffness of the front left spring was determined).Access and distinguishing of these components is however dependent on the modelling tool.Within the CLOCKWORK system, dependent specific tools have been developed for various modelling environments (MATLAB/SIMULINK, SIMPACK).
Another tool for knowledge management on the level of whole models and worlds (the model is a work document) is then proposed.It supports storing, retrieval and search of annotations on the level of whole models and transitions between worlds, the semantic indexing of all objects and hierarchical relations between objects of different worlds (Fig. 10).Informal knowledge can be in the form of a textual description, an image or an arbitrary file.Such knowledge can be associated with all parts of a world object (modelling question-objective, assumptions and environment).

Railway vehicle concurrent design objectives
Within concurrent design of railway vehicles a complete system of different types of railway vehicles will be covered (Fig. 7).

Implementation of the CLOCKWORK methodology for integrated design of railway vehicles
The CLOCKWORK methodology and tools have been used as basis of the system for integrated design of railway vehicles.The system is based on the creation of a simulation model library of various previous designs, using the CLOCK-WORK tools and approach.Thus, these design cases have developed and verified not only as simulation model, but also other mutually related objects in different "worlds" according to Fig. 1.Furthermore, the objects are enriched by formal and informal knowledge, as shown in Fig. 3.When completed, the system will support integrated design of railway vehicles by enabling effective reuse of previous design cases or parts of them.Creating a new simulation model will be much faster than starting from the scratch.

Interpretations of CLOCKWORK worlds
The four world framework (Fig. 1) described previously needs to be interpreted for purposes of the wheel rail design cases library.
The common modelling objective-question is quite general: create a simulation model of a given railway vehicle to enable evaluation of vehicle properties according to code UIC518 (which includes passenger riding comfort etc.).This question is narrowed according to the level of model complexity.
Real world objects are considered as high level objects, which provide a general specification of the vehicle model being developed (geared/not geared, commuter vehicles, high speed vehicles).
Conceptual world objects related to a particular Real world object contain a detailed specification of the modelled vehicle (i.e., number of axes, type of springs, dampers, wheel shape etc.)There are certainly many Conceptual world objects related to a particular Real world object, as there are many structural variants and decisions.
Each Conceptual world object is expanded into at least one Model world object.At this level modelling decisions are made.A decision on how to model each component or piece of a Conceptual world object is made, e.g., which bodies are considered rigid, which flexible, linear/nonlinear characteristics of springs, etc.
The simulation World object below contains implementation of a Conceptual world object in a specific modelling language/package (e.g.SIMPACK, SIMULINK, Adams, etc.).To illustrate some issues discussed above, Fig. 9 and Fig. 10 show an example of simulation model of railway vehicle 711, created using the described methodology.Fig. 9 shows a SIMPACK workspace with an opened simulation model.This workspace enables annotations of simulation model parts.Fig. 9 shows the related record in the CKMT tool.

Conclusions
An approach toward support for integrated design of railway vehicles, a specific and important class of mechani- cal products, has been developed.There is no design procedure based on a sequence or network of related steps for this product class.Instead, previous design cases are used to learn lessons for new designs.In particular, simulation models of previous design cases are reused.Using the CLOCKWORK methodology, means are developed for knowledge capture and reuse.
This work is based on the technology and methodology developed within the EU CLOCKWORK project, adapted for integrated design of railway vehicles.This approach is currently being verified on building a series of commuter railway vehicle simulation models.

Fig. 9 :
Fig. 9: Record of simulation model of vehicle 711 in CKMT -Real world object