Aug 062014
 

ge-transportation-led-lighting-rail-tr6-trio-855x600_tcm201-54906This industrial case study reports the experience of a railway signaling manufacturer in introducing the SysML notation within its development process by means of the TOPCASED tool. Though the tool was later replaced by MagicDraw, the experience is useful to understand the potential of the notation for requirements formalization and analysis, together with the advantages and drawbacks of using an open-source tool in an industrial setting.

The move to MBSE

General Electric Transportation Systems is a company that produces safety-critical railway signaling applications. Given the nature of its products, in 2001, General Electric Transportation Systems started a collaboration with the University of Florence to improve its development process with the aid of formal methods. Along this path, the company introduced formal modeling and code generation by means of the Simulink/Stateflow platform, and defined a model-based process compliant with the CENELEC standards, the set of norms and methods to be used while implementing a railway product for the European market.

These activities were normally performed by General Electric Transportation Systems using a paper-based approach, with natural language documents completed by informal diagrams. Natural language is inherently ambiguous, and a more formal mean to express requirements was desirable. The OMG SysML language was seen as the solution to replace the traditional text-centric specifications with a formal notation. The open source tool TOPCASED was chosen to perform the first experimentation with SysML in a real project.

Reasons to move from TOPCASED to MagicDraw

  1. The SysML language appeared rather intuitive to users with a UML background, and the tool was easy to learn for people with confidence with the Eclipse platform. In general, electronic/telecommunications engineers encountered more hurdles than software engineers, since some basic principles of the model-view-controller pattern are required for a proficient usage of the technologies.
  2. Absence of proper documentation for the tool. Despite the large amount of literature on SysML, there was no complete tutorial to guide people that were new to both the tool and the language.
  3. The notation of internal block diagrams supported by the tool was not compliant to the one presented by the text chosen as a reference, and this caused a limited use of these diagrams.
  4. The stability of the tool. While the model was growing in size, the tool became slower and more prone to crashes, especially with the increasing number of traceability links between different diagrams.
  5. Mistrust in the tool. As a consequence, users did not experiment with many advanced features, such as the collaborative usage. The initial plan allowed the independent update of the model by different actors in different process phases, but ultimately it was the project leader that took care of the integration of the whole model, according to the input of the other participants.

At the end of the project the general opinion was that using an open-source tool to perform core activities in a company with time-to-market pressure and certification constraints was not a good option for two main reasons:

  1. Companies prefer products with a limited but stable number of functionalities, while lively maintained open-source tools such as TOPCASED tend to have several experimental features that are progressively tuned by the community according to the users feedback.
  2. Companies require a direct interface with the tool providers that takes responsibility if a problem occurs with the tool usage.

The choice of Magic Draw was driven by these considerations, and the tool actually confirmed the expectations of a more stable, documented and customer-supported platform.

Modeling state at GE Transportation today

Today the company is proficiently employing the tool on large projects, intensively exploiting collaborative usage features and with a generally good opinion of the tool maturity level, but all the official specifications required by the CENELEC norms continue to be manually edited using natural language documents. Assessors normally enter at the end of the development process to validate compliance with the standards, and require paper-like documents in order to have a complete picture of the activities performed by the company. While this implies a major effort in terms of production and maintenance of the documentation,  the investment in SysML pays off in terms of increased confidence in the quality of the specifications.

The full paper:

Download (PDF, Unknown)

This industrial case study was originally published at http://selab.fbk.eu/re11_download/industry/proceedings-short-papers/RE2011SIP004.pdf

Image source: http://www.gelighting.com

5.00 avg. rating (99% score) - 3 votes

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)

Time limit is exhausted. Please reload CAPTCHA.