• The quality of the system specification is the corner stone for top-down Rolling Stock development (from Customer requirements/needs to product solution). The evolution of railway operators position makes that approach (top-down instead of bottom-up) mandatory.
• Therefore it was crucial for Alstom to put in place an efficient top-down approach by using Requirement Based and Model Based System Engineering (SysML) as an efficient implementation solution.
• The top-down approach mainly consists in:
  • Manage and develop input requirements up through the system engineering, detailed design up to system verification and validation
  • Develop a train operational analysis to elicit costumer use cases and needs
  • Develop a train level functional and constructional architecture which cover train level requirements and use case
  • Develop the sub-system level functional and constructional architecture which cover sub-system level requirement and which is coherent with what defined at train level.
• Requirement Based solution mainly consist in organize all the requirements in a database in order to be able to derive and allocate requirements to different modules which are linked to a specific part of the system architecture (Train or sub-system). That solution permits also to easily manage the change, follow the requirements evolution and create links with the part of the architecture which covers it.
• Model Based solution consists in depicting the System operational analysis, the System and Subsystem architecture (functional and constructional) with SysML:
  • the operational vision elicits and specifies the environment and the specific needs of the customer of the system (the train),
  • the functional vision specifies functions of the subsystems that will cover customer usage and needs,
  • the constructional vision specifies the system configurations that will be implemented in order to perform functions and hence fulfil customer usage and needs (see the figure below).

}}

• Operational vision modelling process consists of:
  • Define the use cases of the studied system by the relevant actors. Use cases specify the services that the actors expect from the system. Actors are roles played by external systems. Actors are outside of the system and interact with it. In this step, the actors interacting with the system are identified. Definition of actors and use cases must result in a clear identification of the scope of the system: what are the missions of the system.
  • Define the operational contexts of the system. A context is a consistent set of actors interacting with the systems and of use cases involving those actors. Nominal and degraded contexts are identified. Degraded contexts are nominal contexts where some of the actors are missing or some of the use cases are not possible. This step also exhibits the possible transitions between the different contexts.
  • Define information exchanged between the system and its environment in order to allow the use cases in a specific context.
  • Refine the operational data model which specifies the physical structure of exchanged information.
  • Refine operational requirements to operational model elements (use cases, exchanged information, contexts).
• Functional vision modelling process consists of:
  • At system level: define a functional architecture to create the expected behaviour of the system to allow the use cases: to each use case shall be defined the functional behaviour expected from each involved subsystem and the related interactions (inputs/outputs) in order to allow it.
  • At subsystem level: Define the subsystem functions in order to allow the expected behaviour defined at system level: to each subsystem expected behaviour defined at system level, it shall be defined the subsystem functions expected behaviour and the related interaction (inputs/outputs) in order to support it.
  • Describe the expected dynamic behaviour of each function
  • Allocate functional requirements to functions.

• Constructional vision modelling process consist of:
  • Define the constructional breakdown of the system by decomposing it into subsystem and of the subsystem by decomposing it into components
  • Allocate then previously defined functions on these elements in order to trace their relationships (check that each function is performed by one and only one element and that each element is required by at least one function).
  • Define the constructional data model which specifies the physical structure of exchanged information between the elements. At subsystem level, the system constructional data model shall be used and eventually updated in case of need.
  • Define constructional interaction points between elements
  • Define interfaces typing the previously defined interaction points and describing the exchanged data and the dynamic behaviour of each interface.
  • Define the constructional internal interactions between elements by defining the constructional data exchanged between elements in order to support functional flow required by the functions performed by these elements.
  • Allocate constructional requirements to constructional elements.

• ASAP methodology is tool-free because no specific language stereotypes or tool profile has been created. Nevertheless the used tools are DOORS for the requirement management and development process and Atego Artisan for the SysML modelling process.

• White papers and articles are available

• Marco Ferrogalini – Jean Le Bastard. ” Return of experience on the implementation of the system engineering approach at ALSTOM”, Complex System and Design Management 2012 International Conference. Paris (France).

Click Here