1

Confidential C

A Model-Driven Approach for Managing Software Development Processes in the Automotive Industry

Frédéric Bessonnier, Renault, frederic.bessonnier@renault.com

Theo Lafontan, Altran Toulouse, theo.lafontan-extern@renault.com

Erich Meier, Method Park, Erich.Meier@methodpark.com

Executive Summary

This paper presents a model-driven approach to the software engineering processes. Our solution allows organizations to efficiently

respond to transformational challenges while still ensuring reliability, security and safety of their products.

In the approach, all software engineering processes are defined in an integrated model that contains standard processes as well as

product-line specific variants and project-specific instances. Processes are automatically visualized from the model instead of drawn

by hand. Software engineers can view the processes from perspectives that are optimized for their specific context, information

requirements, or experience. The processes can be tailored to project-specific requirements and mapped to standards to ensure

compliance to Automotive SPICE, ISO 26262, etc. The Renault solution reduces overhead, makes the organizations leaner, and enables

them to respond to changes in an agile way.

Introduction

Automotive companies are faced with a lot of disruptive changes. Electrification, connected services and autonomous driving are just

three examples that require companies to incorporate new technologies and transform their product development while still ensuring

reliability, resilience, safety, and security of their products. With more and more innovations being implemented as software

algorithms, software engineering has become one of the most important capabilities for an automotive company.

To shorten development cycles and manage the immense complexity of modern automotive software, most organizations adopt agile practices, use model-based engineering approaches, or implement product-line engineering concepts. All those topics have a large impact on the underlying software engineering processes. Now the question is: is this enough to catch-up with the constantly evolving technologies and the new automotive challenges?

Many engineering processes are still managed in document format and distributed as physical process documents, authored in word

processors or presentation tools. Much effort is required to keep these process documents consistent. Changes are only done if they

cannot be avoided and a lot of time is spent in reviews.

In order to figure out which processes to follow, software engineers need to read through hundreds of documents, which often are

outdated and inconsistent. Therefore processes are rarely applied as intended.

All of this is neither agile nor efficient. It is too slow and too expensive to keep pace with the challenges described above. Besides, it

is impossible to meet the requirements of regulations such as the European 858/2018 that requires car manufacturers and their

suppliers to demonstrate conformity to all legal regulations and applicable norms and standards.

Finally, these problems are multiplied by the scale factor: as car manufacturer, Renault develops dozens of vehicles each composed of

many ECUs (onboard computers), containing software. Therefore, all this has an impact at corporate level.

We will describe a modern model-based approach for managing software engineering processes that allows organizations to quickly

introduce new processes, and efficiently adjust existing ones, manage compliance to frameworks and at the same time avoid being

overtaken by their competition.

2

Confidential C

A Model-Driven Approach to Process Management

Related Work and Comparison

SPEM (Software and System Process Engineering Metamodel) and SEMDM (Software Engineering Metamodel for Development

Methologies) are two approaches similar to our process component concept. SPEM defines an extendable metamodel that includes a

distinction between definition and usage of process objects, as well as a variability concept for inheritance. SEMDM has similarities to

SPEM, separates process and instance data, and has a multilevel concept for process instantiation. In comparison to both concepts,

our metamodel and our inheritance mechanism is less complex therefore easier to adopt in practice. Both SPEM and SEMDM lack

concepts for process tailoring and managing compliance.

BPMN is a standardized notation for modeling and automating workflows used by many general BPM (business process management)

solutions. BPMN has a fixed process metamodel and relies largely on swimlane diagrams for process modeling. Through its focus on

IT automation, its inherent technical nature, and very formal notation for alternate process flows, BPMN diagrams are not well suited

for enabling process understanding for engineers. BPMN also does not contain concepts for phases and milestones, or practices, does

not cover proven engineering process techniques like RASIC/RACI or SIPOC, and it lacks support for process tailoring and compliance.

Enterprise Architecture Methods (EAM) like TOGAF, FEA, or the Zachman Framework take a similar approach by modeling process

entities and relationships. The focus of EAM is typically a whole enterprise and therefore too large for our targeted scope. It should

be noted, that our metamodel approach is compatible with the Zachman Framework in that we are using only selected perspectives

and dimensions of the framework. As a result, our models can be embedded and integrated into larger EAM initiatives and models if

desired.

In our solution, we apply two proven engineering concepts to the process management problem:

1. Describing the software engineering processes in a well-defined model and derive variants or project instances from it.

2. Recursively decompose complex software engineering processes into smaller components that are connected via interfaces.

To practically implement this approach, we used the following sequence:

• Create an architecture consisting of a hierarchy of process components that can inherit from each other

• Create models for each of the process components and its interfaces

• Use the models in practice, inspect their usage, and adapt architecture and models based on feedback from their usage

Just like any complex system, Software Engineering processes can be decomposed into components that are connected by interfaces.

For example, as shown in Figure 1, a “Software Engineering” process can be decomposed into:

• Requirements Management

• Software Design & Implementation

• Verification & Validation

Process components can recursively be decomposed in sub-components, for example “Software Design & Implementation” can consist of “Software Design”, “Detailed Design”, and “Code Generation” sub-components.

3

Confidential C

Figure 1: Sample Process Component Architecture

By breaking software engineering processes into model components, changes can be applied faster and with less risk for the overall

process. Review and approval cycles can be reduced, bringing processes faster into practice and improvements quickly into projects.

Process components can also inherit from other components. By using component inheritance, product-specific, or business-unit

specific processes can be modeled. Component composition and inheritance can also be used to create project-specific processes. A

sample process architecture including inheritance for product lines is shown in Figure 2.

Figure 2: Sample Process Architecture with Product Line Process Variants

Analyzing the process description, you`ll find certain process Assets like in our approach, and we use the following elements to express

the different perspectives of a process:

• WHAT should be done: activities and work products

• WHO does it: roles (e.g. using the RASIC/RACI responsible, accountable/approving, supporting, informed, consulting scheme)

• WHEN does it have to be done: phases and milestones

• HOW is it done: practices, methods, tools, metrics, etc.

• WHY should it be done: standards, policies, and regulations (e.g. Automotive SPICE, ISO 26262, or IATF 16949)

Figure 3: Process Component Metamodel

A graphical representation of what we call a metamodel is shown in Figure 3. The metamodel is flexible and can be adjusted to the

organization-specific requirements. Every element is only modeled once. This clearly differentiates our approach from drawing a

process flow, e.g. with Visio, which results in an image, not a model according to our definition. By adding HOW, WHEN, and WHY

aspects, our approach is also better suited for consumption by engineers than process languages like BPEL or BPMN, which typically

only describe the WHAT and WHO aspect.

4

Confidential C

By separating the WHAT from the HOW, the WHAT part become reusable. For example, the difference between managing

requirements for an infotainment system with thousands of requirements, and an internal diagnostic system with a few dozen

requirements, lays in the different practices and tools being used, all being part of the HOW dimension. With our approach, this can

be elegantly modeled with one process component containing then generic WHAT part and two other process components inheriting

from the generic component and adding the specific practices.

The inheritance concept can also be used to create project-specific process instances, the processes can thus be immediately used in

practice and adapted to the project needs, constraints, practices. This allows to directly collect feedback and focus improvement on

specific parts of the process. Through the component-based architecture, changes can be propagated instantly into all process

instances, instead of having to wait for the next publication cycle of the overall process documentation.

The advantages of this approach are:

• The process model can be viewed from any perspective: actors, topics, timing, practice, standard. In other words: “Who does what, when, how, and why”. This allows process users to select the perspective they need for a specific use case, as opposed to a static process diagram that only shows one perspective to everyone.

• The model can be viewed at several levels of granularity (depending the process architecture) and information density: top-level overview or in detail step-by-step. This allows beginners to understand the specific detail process steps and practices, whereas experts can directly navigate to the information they need (e.g. templates, checklists) without being lost in detail.

• The process model can be statically and dynamically checked for consistency and correctness. Process flows can be simulated

and analyzed. Lean concepts can be applied at any stage to detect and eliminate waste, e.g. find work products that are

produced, but never used later in the process.

• Gaps to regulation requirements can be algorithmically determined by checking for requirements that are not mapped to any

process content.

• The impact of changes to the model can be determined, including compliance to standards and regulations.

• Models can be instantiated in and tailored for engineering project contexts.

• Process models can be transformed and automated by an execution platform, e.g. in a PLM (Product Life Management) or

ALM (Application Life Management) system.

User experience is improved / user can get relevant information faster => better understanding of what is expected and

overall efficiency improvement

The most important aspects are discussed in the following section.

Concept Details

Visualization. Over 70% of engineering processes are driven by humans and not workflow engines, so process understanding and

acceptance among engineers is critical. Static process diagrams have the disadvantage to look the same to everyone. From our

practical experience, different engineers need to see different aspects, levels of detail, or perspectives of the process. A very

experienced engineer needs quick access to the latest work product templates through a simple process view, whereas a novice

engineer needs to understand the whole activity flow.

Figure 4: Process visualized as Swimlane with Roles and Phases

5

Confidential C

Some engineers need a cross-discipline view of work products grouped by current phase, whereas another engineer needs detailed

insight into the software process and its practices. With our model-based approach, process diagrams can be automatically visualized,

based on the user’s requirements, context, and perspective.

Compliance

Automotive is a regulated industry where software engineering standards are either mandatory or advised to be used, e.g. Automotive

SPICE and ISO 26262. With our model-based approach, the requirements of those standards can be mapped onto the individual

process elements that fulfill them. This allows tracing standard requirements to process components and even to their project-specific

instantiations and project work products. This allows finding gaps in standard coverage or automatically generating evidence for audits

and assessments. This is especially useful when the gap analysis and evidence generation are applied to tailored processes.

Agile Changes

Agile development is a collection of development practices based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages a rapid and flexible response to change as well as fast feedback loops for the customer and the development team. In our approach, agile practices can be applied to process definition and management. Whereas document-based processes are very

hard to change in a consistent manner, our model-based approach enables efficient assessment of change impact, dependencies, risk,

and possible violations of standard compliance. As every process element is only modeled once, inconsistencies can be prevented.

Using codified model constraints, the consistency of modified processes can be statically and dynamically checked before they get

released. Through the component architecture, changes of standard processes can automatically be merged into product line specific

processes. Changes can be applied very quickly, even to process instances that are already used in projects.

As a result, processes can be modified in short cycles, do not have to go through long periods of review and approval, and can be

applied in practice as soon as possible. Users of our concept have reported a factor 4 reduction of cycle times for process changes

from change request to implementation in practice.

Instantiation and Tailoring

Different product lines might imply process variations based on technologies, methodologies, tools, practices, market regulations,

project complexity, percentage of reuse, available budgets, and many more characteristics. Because there is no absolute process valid

for all project contexts, our approach handles this necessary variability at different levels.

From a reference process model, combinations of process components are composed to match the needs of product lines, e.g. a

process variant using model-based approach, a process variant for code-based approach... the process components selected in a

process variant inherit the inner structure, the properties and the content from the original reference process component.

Then, their specific requirements and projects can be incorporated by a tailoring mechanism. Tailoring starts by the definition of the

tailoring conditions which can be defined in the form of a question-answer tree. The possible tailoring answers are coupled with the

omission or addition of process elements. Next, by answering the questions of the tailoring assistant the project manager reduces the

project instance of the process model to the process elements he needs. A report will summarize which elements were added or

removed by the tailoring assistant and, only the remaining process elements will be displayed as applicable to the project staff.

Nevertheless, experienced process users can further manually adjust the process based on specific customer requirements and then

rationale will have to be provided. For example, based activity managed by a manufacturer equipment can be tailored away.

Tailoring should be implemented through a workflow where the tailoring is required (by Software Project Leader, Quality Manager,

…) and then submitted for approval to experts/managers and these activities should be described in the project management process.

As a result, engineers see only those processes that are applicable in their specific project.

6

Confidential C

The impact of the tailoring could be directly analyzed and a report could be documented with justifications.

Avoiding or reducing the manual process tailoring on a project saves time, in line with shorter development cycles and better time-to-

market, automatically creating a useful tailoring report upon project assessment.

After tailoring:

• The roles can be associated to project stakeholders.

• A work product list for external work (suppliers) can be created

• Tasks regarding a role link to work products / activities will be automatically generated in Task management tool

• The project manager could create the project planning based on the remaining tasks

• Organization link to Configuration management tool and to SharePoint will be created to store future work products

Practical Application: Experiences at Renault with the Alliance Embedded Software Engineering process (ASWP)

In ERTS 2018, Renault presented the article “Renault Nissan new Software Strategy” describing the six levers of the strategic Enterprise

Architecture project executed between end 2015 and March 2019: Software Robustness.

Figure 5: the 6 Levers of SW Robustness

The Alliance indeed started to internalize the software engineering activities to get control over software quality, improve the time to

market, and optimize costs.

Amongst the breakthroughs achieved by this project, were the creation of the Alliance Software Center, and the buyout of the former

Intel R&D sites in Toulouse and Sophia Antipolis to create “Renault Software Labs”. To catch-up with state-of-the-art quality standards,

we began in 2015, the first Renault-Nissan Alliance process : “O52 Develop and Validate the Embedded Software” based on the

Automotive SPICE process landscape.

Similarities might be found between this six Levers and Enterprise Architecture frameworks as Zachman or TOGAF. The focus of this

article is on how we used a specific approach to optimize what was already achieved by the Software Robustness project in the

definition of the Software Engineering process and its deployment.

7

Confidential C

The Renault Quality Management System defines several levels for processes:

Figure 6: Renault QMS process levels

• the highest being the V3P logic where the

company-wide fundamental common rules are

defined, e.g. the common vehicle milestones

synchronizing the development phases of the

entire company around vehicle schedules (the

WHEN);

• at the second level are the Operational processes

per domains such as System Engineering (O53),

Software Engineering (O52), Project Management

(O26), … defining the main activities, the main

inter-domain interactions and the main

deliverables per domain (the WHAT);

• the third level is the Métier level, detailing the

tasks, work products, templates, methods and

tools for the Métier-specific activities (HOW, WHO,

…).

“O52 Develop and Validate the Embedded Software” process V1 (Dec. 2017) was designed to cover both the second and third levels

simultaneously. It was divided into sub processes, for which the responsibility of creating the documentation was clustered between

our specialists and experts. O52 was composed of 160+ MS Office documents as templates, checklists, standards, instructions, and

process descriptions with different levels of abstraction and granularities, and process variants (code-based/model-based,

QM/Safety, …), handled in independent documents.

The dependencies between sub-processes were identified via a SIPOC document identifying mostly bilateral relations (Software

Requirement Analysis and Software Architecture, Software Architecture and Software Integration …), but this empirical analysis was

adapted neither to handle more complex interactions across the different abstraction levels spread in the massive complex

documentation, nor to identify completely all interactions including with the supporting processes as Verification process (SUP.2),

Project Management process (MAN.3), …

This lack of interconnections lead to issues when trying to insure the global consistency and proper distribution of information

between the Operational process level (synthetic) and the Métier process level (detailed). These issues included :

• Redundancies and contradictions (especially for the role distribution),

• Gaps (roles doing nothing while some where involved everywhere),

• Missing templates and trainings,

• Difficulties to map the deliverables and activities onto the project milestones,

• Difficulties to connect to the other corporate processes such as O53 (Design and Validate the Systems).

The deployment of O52 V1 started early in 2018 but the deployment pace was affected by the volume of documents, the complexity

to get to information, and the difficulties to apply listed a above.

Because of these difficulties, Renault-Nissan started a collaboration with Method Park in May 2018. A proof of concept was executed

to evaluate the capabilities of Method Park’s Methodology and the tool Stages in order to improve the process. The model-driven

approach, described above, was used to capture the Automotive SPICE SUP.4 portion of the existing O52 documentation. The principle

was rather simple : map the information contained in the documents inside the corresponding process elements of our metamodel,

defining new element only once, eliminating redundancies, contradictions, identifying gaps, … and then, associating the related

information via association links e.g. task <-> responsible, document <-> template, ...

In June 2018, the Management requested a recovery action plan to bring the benefits of Software Robustness outcomes into the

projects. The action plan, executed through December 2018, is summarized in Figure 8, A continuous incremental improvement loop

was used, where the process owners refined O52 V2 in the MS Office documents based on lessons learnings.

8

Confidential C

The continuous loop was closed by two feedback channels ; first by MethodPark capturing the entire content of O52 scope in their process management tool, Stages, using their methodology ; the second feedback loop came from a beta-testing pilot project.

Figure 8: Process construction Acceleration

Through January 2019 process owners continued to edit the MS Office documents and the changes were duplicated in the tool. It

was recognized that this had avoidable overhead and process owners realized it is easier to improve process quality using the model-

driven approach. Stages then became the official process documentation/modeling environment for ASWP.

Steps followed in 2019:

During the first quarter of 2019, we switched to a fully digital process management and process content edition.

We coupled our approach with a JIRA to collect feedbacks, process issues, and to assist in planning and tracking changes (see in Figure

9). We switched to the new Stages version (v7) which includes a more modern Graphical User Interface. We defined a new heuristic

to fix the most frequent issues not detected by our peer reviews on the MS Office documents. The heuristic does not require specific

skills, it only requires a 2-hour training to explain the metamodel and the Stages interface to the process modelers.

Figure 9: Process digitalization

Within three months over 1700 process issues, found from reviews performed on the MS Office documents, were corrected directly in

Stages.

On the second quarter of 2019, we reworked the overall O52 V2 process architecture in order to split the Operational process level for

Renault QMS. This is O52 (V3 version planned by end of 2019) and the Alliance Software Process (ASWP) for the Software Metier Level.

Process checks with Stages algorithms and consistency improvements has improved our process. Mapping of deliverables to internal

9

Confidential C

Software gates and Vehicle milestones add temporal items. Modelers work in the tool at flat level (no layer and organization between

processes but organization under each process)

In the third quarter of 2019, we started to define an architecture and organize processes and sub processes on a specific workspace to

improve the user experience. We integrated all sub process following this defined architecture. A review of all draft releases has been

completed with experts of each sub process and with people working on current Renault-Nissan projects. ASWP V3 has been released.

This deployment includes trainings and active coaching. SSO security activation on Stages server, interface with JIRA and SharePoint

and quality KPI tracking with MAN 6. Has been completed. We were still at Metier level.

Figure 10: ASWP V3.0 Architecture

In the last quarter of 2019, we will focus our effort on the interconnection between each federative process such as 053 for the System.

We will publish O52 V3 release, and a Proof Off Concept on O53 process is being executed. Because of multiple process owners (almost

one for each process) at multiple levels and the interconnections, the process architecture needs to be re-designed. We will have an

integration layer for each level. This new architecture will enable the creation of process variants.

We will detail our tailoring tree, define our project variants and our tailoring questions and answers. Then we will start the creation of

ASWP variants (model-based/code-based developments …) which are necessary to instantiate a project

Figure 11: Tool model library

10

Confidential C

For next year

We will configure the ASWP tailoring assistant creating questions like “What will be the ASIL (safety) level of your project?“. The

answer will automatically configure the process variant.

We will move our Stages server from MethodPark datacenter to our Alliance cloud and connect it to our JIRA server and to a document

management system.

We will deploy ASWP in Renault projects with a product-line approach, each product-line will apply the same variant of the process

and then a more detailed tailoring will take into consideration the specificity of each project as temporal constraints (gates). These

tailorings will be carried out and justified by the Software Project Leader, and approved by the Experts. Project managers will associate

process roles to their team and all associated task will be created using a task management tool (e.g. JIRA).

We will continue to improve our processes.

Stages allows users to make comments, that can be directly assigned in JIRA and will feed our improvement backlog. We plan to map

ASWP to ISO 26262 and Automotive SPICE requirements. We will also map cybersecurity and other new regulations. The projects will

need to apply their tailored version of the Alliance Software process to inherit the mapped conformity to the automotive standards,

to enable the generation of document packages to facilitate project audit and assessments.

Figure 12: Stages Overview Cycle

Further improvements will be made for the projects. Stages will be integrated with a software engineering datalake in order to

automatically retrieve data to compute the KPI. This will enable a continuous monitoring of measured data rather than KPI’s

calculated by humans. Figure 13 is an example of an automated Quality Assurance Score Card that we will use in projects.

Figure 13: ASWP Project Score car