Automotive engineering is characterized by relying heavily on complex supplier networks as well as by strong dependence from hardware and software component development. OEMs (original equipment manufacturers) coordinate and integrate the work of hardware and software component suppliers and to an increasing amount develop application software themselves (component suppliers can be internal). For OEMs the transition to model-driven development promises potential reduction in the development lead-time of complex in-vehicle automotive features, such as semi-autonomous driving, but it is not without challenges. For example, the veri cation of such features is still performed using mainly physical properties such as hardware benches and mule vehicles. While this step is necessary, it is not su cient, because it does not allow early veri cation of design decisions to the required extent. In addition, the development speed of hardware and software components is (a) limited by hardware development cycles as well as (b) slowed down by unsynchronized software development cycles of key suppliers. This prevents detailed information from being available early and potentially resulting in expensive and late changes. Understanding this situation as an ecosystem of cross-organizational collaborations allows us to reason about challenges and opportunities of the interaction between the OEM and di erent component- as well as tool-providers. In this paper, we report rst results from an exploratory study that involved interviews with one of our industrial partners, General Motors (GM). First, we describe our understanding of the automotive ecosystem. Second, we explore interactions and roles of di erent ecosystem actors based on workshops and interviews with engineers at GM.
the automaker (OEM, original equipment manufacturer) starts with high level design of the feature, maps it to the overall system architecture, and derives hardware and software requirements, which are most often given to suppliers for implementation. Once the suppliers deliver hardware and software components, the OEM starts integrating them into a nal product. The complexity of design artifacts and supplier networks lead to the need to coordinate and verify design decisions across organizational borders.
With few exceptions, OEMs address feature development in a way that
resembles the waterfall process, characterized by upfront requirements analysis, early
design decisions with limited knowledge, and by being able to verify the success
of the development only later in the process after integration of the components
into a mule vehicle (a complete, often drivable vehicle with experimental and
prototype components). This situation can lead to sub-optimal decisions, which
often result in late changes and rework. Lean software development considers
this to be waste and suggests to change the process in a way that allows to make
design decisions later, based on knowledge about the performance of a number of
candidate solutions [
In this paper, we report rst results from an exploratory study in which we aim at understanding coordination needs between actors in the automotive value chain by interpreting it as an ecosystem. Our contributions are (i) a characterization of the automotive ecosystem based on related work in software ecosystems, (ii) a rst sketch of crucial interactions and roles of di erent ecosystem actors based on workshops and interviews with engineers at GM, and (iii) a discussion of challenges and opportunities of changing the ecosystem in a way that supports to make binding decisions (decisions that would be expensive to reverse such as contractual or architectural decisions, e.g. about a certain microcontroller) later and to do early non-functional veri cation across organizational borders earlier. 2
This paper provides a rst step towards describing automotive engineering as an automotive ecosystem of interacting organizations and is based on our collaboration with engineers and technical leaders at GM based on the following research questions: RQ1: Who are the actors and what relationships exist among actors in the automotive ecosystem? RQ2: What are examples of challenges and opportunities that currently exist in the automotive ecosystem?
To answer our research questions, we start by characterizing and de ning the scope of the automotive ecosystem based on related work in the eld of software ecosystems. We then follow up with a qualitative case study based upon worked done at GM R&D to further our understanding of such an ecosystem. At this stage, our research is exploratory in nature and the preliminary results we present here are based on aggregating discussions during workshops and unstructured interviews. In future research, we want to engage with representatives of potential internal and external actors in the automotive ecosystem in semi-structured interviews, with the goal to elicit a clear understanding of actor relationships and their coordination needs as well as measurable objectives to measure and continuously monitor success, health, and gains of the automotive ecosystem. 3
In this section, we explore relationships and interactions of actors in the
automotive ecosystem based on literature on software ecosystem and interviews as
well as workshops. We start with an example of how actors collaborate in
automotive supplier networks and characterize this ecosystem based on related work
in software ecosystems, before we report preliminary results from our ongoing
interviews with practitioners on how these actors interact to create value. This
is a rst step towards a more formal assessment of the automotive ecosystem
(e.g. based on [
Characterization of the Automotive Ecosystem
In understanding ecosystems, one would draw on three elds in software
engineering: open source software [
Previous research proposed [
Automotive engineering depends to a large degree on collaboration across
a large supplier network, which generates a signi cant coordination need. It
is characterized by the integration of di erent hardware and software
components, thus it is touching on various levels in the ecosystem stack [
All of these components can be provided by di erent suppliers or be
developed in house at the OEM, who is also responsible for integrating the di erent
inputs. We would thus see the OEM in the role of an ecosystem coordinator and
characterize it in terms of Jansen et al. [
This integration requires to make binding decisions which typically, in
automotive engineering, need to be made before the application problem is completely
understood. Making such early binding decisions can lead to late changes (e.g. if
the hardware is too weak to support a given algorithm), or to waste (e.g. if the
hardware is more powerful and more expensive than required). Both problems
can only be discovered late, during non-functional veri cation and validation
through testing. Based on Farbey et al.'s classi cation of inter-organizational
relationships, we classify the automotive ecosystem to operate on Rung 1 (market
relationships with dominant focal rm) or, in some cases, where embryonic
networking among actors occurs, as Rung 2 [
Consider for example a case, where the OEM is developing the application software component in house. R&D Engineers would develop a new control algorithm, using Simulink for model-driven development and simulation to allow functional testing, before hardware is in place. System designers would then decompose the Simulink models and generate software from Simulink blocks. By using for example software-in-the-loop based functional veri cation, this development is independent from the ECU hardware development, which can be started in parallel as soon as the hardware requirements are su ciently understood. However, non-functional veri cation on the integration or system level can only be done once the hardware is developed and the execution time of the application tasks on the target hardware can be measured. 3.2
Actors and their Relationships in the Automotive Ecosystem.
To identify and discuss the coordination needs of the ecosystem actors, we
analyze one typical scenario in the automotive domain that uses MDD
(ModelDriven Development) to provide a situation where software can be developed
prior to the availability of MCU (Micro-Control Unit, part of the ECU)
hardware. The same target code compiled for the actual MCU can be run on the
simulated MCU at close to real time speeds and high degree of timing delity.
Fig. 1 shows the actors and their relationships, as provided by one of our GM
interviewees [
The 3rd Party Tool Provider contributes a model of the rest of the system, the plant model, which typically includes both a simulated controlled plant (e.g. an engine) or at least a simulation of the digital interface to it, as well as the simulated incoming messages from other MCUs in the system. This model allows the target code to interact with other parts of the system before these have been nished. Such models are usually exchanged using a third part tool format. For example, for an engine model in Simulink, a MDL le is exchanged, while for the network message model as Vector DBC le is included.
The Tool Provider contributes a standardised simulation environment (e.g. based on SystemC, a set of C++ classes that provide event-driven simulation) to (1) run the simulated MCU (2) execute the target code for the actual MCU on the simulated MCU.
The Tool Integrator combines both tools into the Rest-Bus Tool Integrated Environment, which allows OEM users to do Rest-Bus Simulation. Rest-Bus Simulation is a technique used to validate ECU functionality by simulating parts of an in-vehicle bus like the controller area network (CAN).
The Core Processor IP Model Provider provides a core processor model of the intended hardware (usually an MCU). The Peripheral IP Model Provider provides a model of the peripherals in which the core processor is embedded. The MCU Provider will provide the hardware (typically, this is done by an automotive Tier 2 supplier).
The MCU Model Quali er ensures the requested level of accuracy of the model in representing the MCU hardware. Currently there is no formal de nition of this role or default processes to qualify or certify the accuracy of models, yet this would be crucial to overcome challenges as discussed later in this paper.
The MCU Model Integrator uses Core Processor and Periphery Models to create a MCU Model. The Solution integrator integrates all models and tools into an integrated simulation environment.
The OEM user develops the application software component, which relies on the MCU hardware. It is important, that the development can start before the availability of hardware, but also that design decisions can be non-functionally veri ed early in the process. As development proceeds, uncertainty is reduced and more knowledge about constraints becomes available. Also, a higher accuracy of veri cation becomes necessary. While for later veri cation, a hardware board is crucial, the availability of a virtual board early can be an asset, if adequate accuracy is provided. 4
Based upon the work done in GM R&D, our GM interviewees have stated that one of the biggest opportunities of the automotive ecosystem is to enable its actors to share accurate models of hardware, periphery, and middleware software early and continuously in order to facilitate later binding decisions and early non-functional veri cation. These models could then be partly re ned as more knowledge becomes available. For this, development partners (e.g. OEM, Tier 1 and 2 suppliers) need synchronization points where they share their current level of knowledge. Examples of these include: { OEM shares current version of Simulink prototypes and models with other actors in the ecosystem. { Tier 1 regularly shares information about the task composition and the characterization of task execution time as it becomes available. This allows the OEM early simulation and non-functionally veri cation.
Model provider HW Design
Certify model Accurate model accuracy Tool provider
Tier 2 supplier HW Integrated tool chain
Tier 1 supplier
Basic SW
OEM { Tier 2 shares information about the microcontroller design and its capabilities. This allows the Tier 1 supplier to estimate task execution times.
To increase the e ciency of this information exchange, our interviewees suggested to consider tool providers as part of the ecosystem, as they enable interoperability and exchange of relevant models. Also, while Tier 1 and 2 suppliers can be model providers, it could be preferable for some to rely on external modeling experts to create accurate models of their hardware in development.
From these observations, we extracted a more generic view on the automotive ecosystem (see Fig. 2). Basically, our study so far revealed two value chains relevant to automotive ecosystems. First, we identi ed the classic automotive value chains, where the OEM relies on delivery of HW and SW components by Tier 1 and 2 suppliers. Secondly, in order to support early non-functional testing (and consequently late design decisions based on accurate knowledge), a second value chain needs to be introduced to provide and certify accurate models of the HW in parallel to the main development stream (gray actors in Fig. 2). A Tier 2 Supplier might provide such models themselves or rely on an external Model Provider. Further, the accuracy of the models with respect of non-functional properties needs to be certi ed to create reliable models that allow testing target-code-in-the-loop (TCIL, a new simulation paradigm where application code compiled for the actual MCU runs on a simulated MCU). Opportunities in the Automotive Ecosystem. The envisioned automotive ecosystem as sketched in Fig. 2 provides opportunities for win-win sscenarios, because actors are not competitors. Tier 2 suppliers for example would gain a competitive advantage if they can more easily integrate into such an ecosystem, e.g. by collaborating with model providers (or by taking that role themselves) in order to provide models of their hardware early and update them regularly so that their accuracy continuously grows until the hardware is completely developed. Tool providers will bene t from a larger market of their integrated tools, which enable the TCIL cycle. Tier 1 suppliers would bene t from the ability to run regression tests on virtual boards quickly.
Challenges in the Automotive Ecosystem. As of today, OEM users may
decide against sophisticated models of hardware as they can be more expensive
than a hardware evaluation board, especially when considering that currently
there is no formal and independent certi cation of the accuracy of models.
Potential time-saving opportunities are typically not exploited because non-functional
veri cation can only start when the evaluation board becomes available.
Acceptance of modeling can depend on availability of certi cation processes. Our
interviews identify the lack of certi cation as one of the main technical
challenges. A clear process for the quali cation of models needs to be in place and
best practices as well as standard collaboration models need to be de ned. By
this, the MCU Model Quali er actor in Fig. 1 appears as one of the key roles in
the ecosystem to allow for transparent and reliable assessment of model accuracy.
Introduction of MDD might impact ecosystem health. To enable a healthy
ecosystem, it should be avoided that a keystone player becomes a dominator [
In this paper, we analyzed the automotive value chain and supplier network as an ecosystem and explored the extent to which this allows us understanding actor relationships (e.g. information ows), challenges (e.g. coordination needs) and potential for optimization. An accurate charting of the automotive ecosystem landscape requires more interviews with technical leaders at OEMs, Tier 1 and Tier 2 suppliers, tool providers, and potential model providers and quali ers. We report now on this ongoing work to gather feedback on our intended approach to understand the automotive ecosystem.
The ecosystem perspective o ers a unique chance to analyze actors and their relationships in the ecosystem and to uncover challenges as well as opportunities, as shown in the example of the TCIL case. In previous work, we found that navigating the tradeo s between protecting intellectual properties ! openness Act proprietarily, confidential VD&I
Act openly, transparent VD&I Act globally: strategic VD&I
tradeoff
Act locally: ‘just-in-time’ VD&I
as well as between global top-down approach ! Responsive bottom-up approach
generates opportunities for shared understanding of requirements between actors
in an ecosystem [
Future research should engage in a more systematic analysis of the actors' information and coordination needs as well as of how to optimize the information ow between them. This is a unique chance for the modeling community, which is called to provide mechanisms for e cient exchange of requirements, design decisions, and models between di erent organizations. We plan on furthering our discussions with more industrial partners in the automotive industry and broaden as well as validate our understanding of their ecosystem and its challenges, e.g. in the context of Autosar (www.autosar.org). Our long term research goal is propose and develop, in collaboration with industrial partners, solutions towards these challenges.
This work was sponsored by NECSIS and Software Center (an industry-academia partnership, hosted by Dept. of Computer Science and Engineering, Chalmers j University of Gothenburg). We would like to express our special gratitude and thanks to our contacts and interview partners at GM { this work would not have been possible without you!