Plastic Omnium (PO) provides plastic fuel and emission reduction uid systems for car manufacturers. These products, must be customizable to respond to di erent manufacturers needs while being compliant to ISO26262 and A-SPICE standards. To satisfy these needs, PO employed a development approach where system functional speci cations are document-based, and software architecture design conforms to AUTOSAR. However, this approach requires to manually translate between textual speci cations and software models, usually rising inconsistency and maintainability issues. This paper reports on the lessons learned with the introduction of a full model-based approach to solve the issues identi ed in its former approach. The proposed approach is evaluated on a real case study using the open-source Papyrus tool.
Page 27
Plastic Omnium (PO) is the world leader of automotive blow-molded fuel
systems. In 2015, PO has produced 18.8 million of plastic fuel tank systems.
Furthermore, PO is one of the main suppliers of Selective Catalytic Reduction (SCR) [
Recent market trends impose more exibility in automotive product
development. A complete system may be share between several suppliers, each supplier
being responsible for a coherent subset of sensors, actuators and controllers. To
respond to these new business cases, PO decided to develop its systems by
decoupling the hardware controller from the application software. The application
software is henceforth developped following the model-based AUTomotive Open
System ARchitecture (AUTOSAR) [
An important challenge in adopting AUTOSAR into the development
approach is that there is manual modelling to be performed at lower levels from
the text-based speci cations. Manually translating the speci cations into
AUTOSAR models is extremely time consuming and error prone with regard to the
large set of documents and di erent stakeholders involved. As a consequence,
there is a breakdown in the traceability chain rising, among others,
inconsistencies and maintainability issues in the development process regarding an ISO26262
[
The objective of this paper is to report on the impact of the introduction
of the MBSE approach and tools at PO with regard to the challenges faced
with the former approach. The MBSE approach aims at developing a
coherent and rigorous product end-to-end development process which gives back to
traceability a central role. The intent is also to better address the requirements
in terms of architecture, quali cation and certi cation for automotive systems
as recommended by standards like ISO26262 and A-SPICE. The key
components of the approach are modelling languages, a modelling methodology and
a modelling tool. PO chose the System Modeling Language (SysML) [
The remainder of the paper is organized as follows. In Section 2, we highlight the challenges faced by PO with its former DBSE approach. Section 3 describes the conceptual components of the adopted MBSE approach. In Section 4, we evaluate the major features of the approach on a real case study and we discuss the outcomes observed in Section 5. Section 6 concludes the paper and sketches some future perspectives. 2 2.1
To specify and design controlled systems that meet automotive manufacturers' expectations, PO has been following a DBSE approach. The speci cation and design processes map the left side phases of a V-cycle.
The processes are re ned through 5 ab- Project straction levels as shown in Fig. 1: The Requets Project Requests level to elicit the systems gToeaclhsnaicnadl uSspeeccaisecsattioonsat(isFfTy;ST) hleevFeulncttoiodnea-l FTS safetPylaantoalysis ne system functions, their performance and safety requirements, and interfaces; the Ar- ATS chitecture Technical Speci cation (ATS) level to design system functions with basic architectural blocks; the Component Techni- CTS simPulalatotion cal Speci cation (CTS) level PO to specify and assess components perimeter and tech- Supplier nical requirements; and the Components Im- Software plementation level to design and develop the Fig. 1: PO DBSE Approach components.
The DBSE paradigm provided a working environment at PO based on the di erent phases of the development process. For each phase, there are several documents of di erent kinds that are de ned for addressing dedicated customers, designers, suppliers, testers needs, etc. The documents structuration and organization was constructed at two dimensions: 1) vertically to keep a consistent abstraction level information within the same document, e.g. function versus component requirements, 2) horizontally to highlight speci c information within one abstraction level, e.g. algorithms description and variables libraries.
In principle, the produced documents are logically related to each other according to the development process. The DBSE approach included capabilities to express traceability relationships between di erent documents as well as between the concepts depicted within a document. The relationships allow specifying the client and the supplier of the documents, while making use of di erent semantics (use, coverage, validation, etc.) to link them.
An IBM-based tool chain was advantageously deployed to support the requirement management, traceability, releases, review process, publication and to limit as much as possible manual operations to handle the methodology. 2.2
When PO was re ning its development process to address the new business
opportunity constraints, the DBSE approach raised several issues related to project
planning and timelines, design information speci cations, traceability, tool
support, collaborative work and standards compliance.
(1) Project work ow and planning. In a DBSE approach, the document
is the main work artefact and the container for requirements and design
information. The project team is focused on the document process which consists
in writing, reviewing, updating and publication sequential steps. The document
contents are frozen in order to be released according to the project timelines. The
latter are aligned with business objectives rather than requirements and design
issues. There is a huge workload to apply rigorously the sequential document
process. To reduce delays and publish speci cations on time, high level and low
level activities are done in parallel. However, this requires an additional e ort
to maintain coherence and consistency in project information. Consequently, the
documentation is often late de ned and may become obsolete immediately
after their publication. Since the unique representation of the information are the
documents, the speci cation updates are not available before the next release.
(2) Design semantics. In the DBSE approach, the speci cation documents
capture requirements and design information in a textual format. Some design
aspects are depicted with charts, for illustration purpose of a textual statement
only. The drawback is that Natural Language is not suitable to describe some
design concepts, e.g. system architecture, and technical choices may wrongly be
expressed as requirements. The consistency between text and drawings
information is also di cult to establish: over speci cation may appear and then create
extra work in the project, e.g. too complex design, additional validation, etc.
(3) Traceability. The DBSE approach focuses on dealing with textual
statements. Traceability between high and low levels design information is very
limited since the drawing elements are not traceable. Therefore, design allocation
across abstraction levels is di cult, which undermines the coherence between
the system level and AUTOSAR software architecture. Traceability is mainly
achieved for documents releases. It is an inconvenient when a change is requested
between releases, because impacts are not fully supported by traceability. It is
then di cult to estimate time and costs to ful ll change requests.
(4) Communication. Team communication is supported by document
publications, which are synchronized with document releases. Additional drawings,
presentations are built on demand to support external communication. However,
particular aspects of the system are hard to understand and communicate since
the information is spread in several documents or not properly highlighted by
the document format.
(5) Tooling. The DBSE approach relies on a set of commercial tools which
let appear some limitations for PO needs. The requirement management tool
DOORS [
Drawings are edited in another environment and then copied in the
documents. Publications are done through a publishing engine which allows
generating appropriate documentation based on module content. The safety analyses
are performed at FTS level using the commercial tool Plato [
Regarding all the limitations identi ed with the DBSE approach, PO decided to shift from its document-centric approach to a model-centric approach. 3
The INCOSE de nes MBSE as \the formalized application of modeling to
support system requirements, design, analysis, veri cation and validation activities
beginning in the conceptual design phase and continuing throughout
development and later life cycle phase [
The most known system-level architecture description languages in the
automotive domain are EAST-ADL2 [
In [
SysML diagrams* Abstraction layer
Technical Specification purpose Key model element S(SyyssteTSm) fOwupintehcrtatiohtineoanelinatlvieVirsio,enmwmapeionninettnciovdinerosntntitimfuyeeinnngttsscyosntsetmituferonntst,ieinrst,esryasctteiomns PUKCG,BDD, IBD, AUcsteocrase Fu(nFcTtSi)on FFpuuennrfccottriioomnnasanl(ciVneipecuwrittpse/oroiinaut,tpfraeuuftilsnt,itnbogelheSrayavsniTocSresb),yreidqeunirteifmyienngtSsy,stem PRAAECQRT,,,SPBEKDQGD,,SITBMD,, SRyesqtueimremFuenncttion (SysML Block) Arch(AitTeSc)ture rBOearagsliaiczneBiclSoyAcsrktcsehm(isteeFncutsnuincregti/oVanicestwuaptoiningt, rperfoinceinsgsiFnTgS) bayndidheonwtifythinegy PRKEQG, BDD, IBD, SDyesstiegmnBFluoncckt(ioSynsDMeLsiBglnoc(Sk)ysML Block) Com(CpToSn)ent oCBfoasHmicWpBo/lnSoWecnktsm-aoocrdiceuonlretdesindgVtioewapnoaibnsttrreafcintitnagrgAeTtSpblaytfaosrsmemmbalidneg PRAAECQRT,,,SPBEKDQGD,,SITBMD,, BHeWhaavniodrS(WSysmMoLduAlcetsiv(iStyy)sML block) AUTOSAR SW component
S(oSwftwCTaSr)e Building a SW architecture aligned with AUTOSAR SBEDQD,,SIBTDM,,APCKTG, Ifnlotwer)nal Behavior (AUTOSAR runnables * UC: Use Case, BDD: Block Definition Diagram, IBD: Internal Block Diagram, PKG: Package Diagram, REQ: Requirement Diagram, ACT: Activity Diagram, SEQ: Sequence Diagram, STM: State Machine Diagram, PAR: Parametric Diagram
Fig. 2: Components of the MBSE Approach Modelling methodology. PO de nes its modelling methodology based on 5 abstraction levels. The speci cations are realized in the System Technical Speci cation (SysTS) and Functional Technical Speci cation (FTS) models. The system design is achieved in the Architecture Technical Speci cation (ATS) and Component Technical Speci cation (CTS) models. The AUTOSAR implementation is achieved in the Software Component Technical Speci cation (SwCTS) model. Table 2 presents the main goals of the di erent models with their associated diagrams and key model elements. Traceability relationships like realize , satisfy , re ne , assembly , etc. are used to trace the above mentionned models. Fig. 4 shows a traceability crosscutting view from SysTS to SwCTS level.
Modelling framework. PO chooses Papyrus [
Fig. 3: Example of diagrams at SysTS, FTS, ATS, CTS, SwCTS levels DOORS and Papyrus. It was simpler to integrate Matlab with the framework as they are both model-based environments. 4
To initiate the transition from DBSE to MBSE, di erent training sessions were
organized in order to convey a uni ed meaning of MBSE to PO team. A
representative excerpt of the Selective Catalytic Reduction (SCR) [
Case study description. The SCR main function is to provide a ow of NOx Reduction Solution (NRS) uid to the exhaust line and the injector from the tank. It relies on environment features (temperature, atmospheric pressure, etc.) of the tank as well as car information (modes, wake up) to provide heating and power energy to them. It also monitors NRS tank temperature, quantity, quality and availability of its actuators. SCR uses communication bus to receive car information and send feedback to the vehicle.
Case study modeling. The SCR missions were modeled at the SysTS level with a Use Case diagram (Fig. 3(A)). Each use case is represented by a SF in the system description at FTS level (Fig. 3(B)), further re ned with Sequence Diagram. The SF include a State Machine Diagram that describes its behavior. At ATS level, each SF is decomposed into sensor, actuator and processing blocks in an IBD (Fig. 3(C)). At the CTS level, the blocks from ATS level are combined into mechanical modules (interface with the physical world/laws), hardware modules (sensors/actuators), application modules (pure SW modules) or driver modules (SW modules that need speci c interface with the hardware).
These modules are used to build the abstract HW/SW platform. A Parametric Diagram re ned them to implement the physical laws triggered by actuator commands. At SwCTS level, application and driver modules from the CTS level are realized with AUTOSAR composite or atomic SW components concepts (Fig. 3(D)).
Traceability is achieved between the abstraction levels (Fig. 4). At the FTS level, System Functions re nes Use Cases from SysTs level. At ATS level, the System Function Design realizes the System Functions. At CTS level, Design Blocks from ATS level are assembled into modules to build the HW/SW platform. Here, the algorithms may be embedded as Activity Diagram into processing block. At SwCTS level, AUTOSAR SW Components realizes the CTS SW modules and the algorithms are mapped to the Fig. 4: Traceability crosscutting view runnable entities of these components. from SysTS level to SwCTS level 5
In this section, we highlight the bene ts and limitations brought by the MBSE approach with regard to the DBSE approach ones (see Section 2). (1) Project work ow and planning. Documents have been advantageously replaced by a global model as a speci cation and design environment. Project planning is notably less constrained as by a sequential work ow of documents writing. As a result, it is possible for engineers to work simultaneously on distinct levels. Design is henceforth elaborated earlier and evaluated iteratively. Traceability ensures consistency in this process between higher model elements and their lower level realization. One unanticipated nding was publication e ort to convert models into documents according to quality process. (2) Design semantics. SysML models and associated diagrams have replaced structural and behavioral design descriptions in natural language and illustrations. The results of this study have highlighted how over speci cation may have existed in previous project due to inappropriate use of textual requirement to depict design aspects. Balance between requirements and design activities is recovered with formal, consistent, traceable and correlated model elements. SysML also tackles complexity and foster reuse via the reusing blocks as parts in IBD. (3) Traceability. The MBSE approach helps to automate traceability which facilitates justi cations and global consistency with regard to certi cation issues. The SysML traceability relationship types support all the former DBSE traceability with important improvements because they are integrated in the model itself. The trace model enables having continuity through the di erent abstraction levels, from system representation to AUTOSAR runnables. The traceability can be exploited for automated checks, e.g. validation rules, change impact analysis or requirements coverage. (4) Communication. The MBSE approach facilitates communication between the stakeholders concerned by the system under consideration. First, it allows specifying requirements, architectural design, and behavioral aspects in a unique and semi-formal formalism: SysML. Second, dedicated viewpoints or additional diagrams can be constructed from the same model if needed either by the methodology, or for design and communication purpose. Documentation outcomes are still generated according to stakeholders needs (customer, designer, suppliers, testers, etc.), but the publication is now realized on demand by extracting model elements and it is not only linked to project publication milestones. Additional communication challenges have nevertheless risen between engineers dealing with technical aspects in SysML and documents reviewers or approvers. A special e ort has to be done to simplify SysML in a viewer tool and to deploy PO Domain Speci c Language (DSL). To reduce this skill issue and associated business risks, training are available for employees and SysML is required for new hiring. (5) Tooling. Papyrus tool has been deployed to support the MBSE approach. PO exploits the customization features of the tool to build its own environment. To ease the transition from DBSE to MBSE, PO implemented a gateway between DOORS and SysML. It has allowed importing and replacing the existing textual requirements with new model elements. PO uses the native papyrus SysML and AUTOSAR editors to support the de nition of the di erent models required by its modelling methodology. To address further concerns, PO uses several pro les on top of their system modelling. A dedicated pro le enables to automatically perform dysfunctional analyses compliant to ISO26262 recommended practices. Another plug-in enables to import and export modules from SysML to Matlab while keeping them synchronized. Papyrus also allows document generation in order to support document releases. Furthermore, with Papyrus, it is easy to deploy a dedicated con guration for a small skilled team. A tool chain responsible role and associated processes have nevertheless to be created to support the deployment in a large scale international team. (6) Standards Compliance. The MBSE approach allows a smooth integration between speci cation, design and implementation levels. With this approach, there is no longer a gap between high-level system speci cation and its AUTOSAR implementation. The automated traceability mechanisms, done continuously as part of the de nition and decomposition process, helps meet A-SPICE expectations and respect the top-down approach fostered by ISO26262. 6
This paper presents the MBSE approach for the speci cation and design of controlled systems in deployment at PO. The approach is built on 3 main components, namely the SysML and AUTOSAR modelling languages, a methodology de ned over 5 abstraction levels and the Papyrus framework that supports the latter. We report on lessons learned from the application of the approach on an automotive system. The experience highlights how the MBSE approach responds to identi ed issues in the former PO DBSE approach thanks to an enriched design capability and to an end-to-end traceability in development process. Thanks to Papyrus, it leverages interest for integration of further concerns, e.g. dysfunctional analysis, design simulation, code generation. The MBSE approach also presents promising assets to facilitate process and product certi cation.