Dealing with heterogenuous systems is often described as a technical challenge in scienti c publications. We analysed data from 25 interviews from a study of Model-Driven Engineering at three companies and found that while the technical aspects are important, they do not encompass the full challenge { organizational and social factors also play an important role in managing heterogenuous systems. This is true not only for the development phase but also for enabling early validation of interdependent systems, where processes and attitudes have an impact on the outcome of the integration.
Complex systems, consisting of numerous and interdependent subsystems [
To explore to what extent language integration for comlex systems is a challenge in terms of technical, organisational and social aspects we analysed data collected at three di erent companies, looking for evidence regarding the motivations and challenges of heterogenuous development of embedded systems. Among the ndings are that engineers tend to favour integration at the concrete code level instead of at the more abstract model level, that management needs to t the right team with the right task and that which language you use identi es you as a software engineer.
The following section will describe the context of the three companies as well as how the data was collected and analysed. Section 3 structures the ndings according to technical, organizational and social aspects of language integration. We then conclude and present our intentions to further investigate the interdependency between the factors in Section 4. 2
During 2013 we conducted a case study of MDE at three companies { Volvo Cars Corporation, Ericsson AB and the Volvo Group. The respective organisations had di erent experiences with MDE but were all transitioning towards a more agile way of software development. 2.1
Electronic Propulsion Systems (EPS) is a relatively new unit at Volvo Cars with the responsibility of developing software for electric and hybrid cars. MDE was introduced in a step-wise manner as software development went from prototype vehicles to mass-production. The overall system design is described using AUTOSAR1 while the software developed in-house at EPS is implemented using Simulink2. Simulink is also used for validation and integration purposes. The interfaces of the Simulink models are generated from the system-wide model. Besides graphical modelling languages, C is used for low-level details while numerous scripts help in everything from translating between di erent AUTOSARstandards encoded in XML to deploying software on hardware.
Radio-base stations at Ericsson AB has employed di erent MDE technologies
since the late 1980's, primarily focusing on UML as a descriptive and prescriptive
modelling language including code generation. Besides using UML for design,
implementation and testing various other languages form the engineers' tool box;
C is used for functionality relying on optimal hardware performance, Java has a
niche in functionality requiring GUIs, Erlang is regularly used for testing while
home-made domain-speci c languages { DSLs [
Volvo Group Trucks Technology develops software for the Volvo Group's truck brands. While most of the software development is outsourced a few features are developed in-house using C. The interfaces of the top-level software components are automatically generated from the system model which is described in a company-speci c dialect of EAST-ADL3. The two Volvo companies are independent in all aspects besides the name space which they share for historical reasons. 1 http://www.autosar.org/ 2 http://www.mathworks.se/products/simulink/ 3 http://www.east-adl.info/ 2.2
The main source of data comes from 25 semi-structured interviews { 12 at Volvo
Cars, nine at Ericsson AB and four at Volvo Trucks. The reason for fewer
respondents at Volvo Trucks is that they entered the project later than the two
other companies and have fewer engineers involved in MDE tasks. The interviews
were audio-recorded and then transcribed. The interviews were complemented
by a combination of observations, informal interaction [
The data has previously been analysed regarding the impact of tools on
MDE adoption [
As seen in the previous section, a variety of languages is used across the software. The variation comes both in terms of adapting languages depending on the nature of the included subsystems, but also due to where in the lifecycle the language is to be applied. 3.1
From the interviews a recurring theme is that the tool used for encoding a solution is just a means for producing low-level code. The following quote is from Ericsson, \I don't see Rose RT or another modeling tool as a language. It's what they produce that is the language, and mostly it's always been C++ for us. So I don't think { I can consider, for example, Rose RT as a tool like Eclipse or something. Lets you develop code." A similar experience was encountered at Volvo Cars when one interviewee was asked about the impact of changing implementation language from C to Simulink, \You still have C code."
The emphasis on the generated language is also dominant in how multiple
languages are to be integrated. Where academic research is focused on
composing modeling languages on a meta-level [
Due to the number of suppliers and sub-contractors both Volvo companies rely on being able to integrate their subsystems in the form of binaries, so that merging on a meta-level is impossible. However, having access to the source would still be bene cial but for debugging purposes, not for merging the partial solutions.
One of the few examples where two languages are integrated in the same development environment comes from Ericsson where a DSL for testing was developed internally, \The reason for it being that it could often take quite long time to compile some of our models [. . . ] from a few minutes up to a few hours, depending on how big the model was." The answer was to de ne their own testing language on top of the modeling language and the interviewee was told that the DSL was developed during all the hours the team sat waiting for the model compiler to terminate. 3.2
An engineer at Ericsson expressed the need for management to assign tasks according to the skills of the developers. \In the big systems, we have di erent languages. Yes, and that is complex. And that's a problem. It's hard to expect that the software designer or veri er is equally good in all languages. And we've had to handle that in our team."
While one engineer at Ericsson saw the need for di erent languages according to domain and platform constraints { \so you have all these levels and you have very di erent requirements for di erent parts of this product. It's so big that I don't even think that one solution ts all. You should be able to use several approaches" { there is still an organisational wish to limit the number of languages to limit accidental complexity \you shouldn't do it without a need. So you shouldn't { if you try to solve the same problem, I think you should try to use similar language or similar ways of working."
Stable interfaces in the decomposition of complex systems is desirable [
Social Aspects of Language Integration \If you go to a di erent language, like, I don't know, whatever language, it will say that the for loop looks like this, but the functionality of it is the same. It doesn't matter how you put it in the words. Instead of 'for', you put like an 'f ' or whatever. It's the same functionality. So when you know the base, you don't need to learn, like really study the new ones. You only adapt to them. From my point of view." The quote is from an engineer at Volvo Cars who explains his perception of using di erent languages for similar tasks.
However, not all engineers are interested in learning new languages. One interviewee from Ericsson described his experiences from developing a customer interface with a team located in a di erent town in the following way, \an option was to do it in C++ because that's the most cost e ective way. And the owner said something like 'I don't think that's a good idea because the organization we're from, people are working there because they want to do Java'."
At Volvo Trucks a similar sentiment was aired as the topic of introducing a new modelling language was raised, \we have a lot of people that like to write C code and they like script languages. And they always do scripts for something. And they are pretty comfortable. They like writing a code with a blank page just writing C code." 4
From a technical aspect of heterogenuous language integration there is a
difference between the emphasis of academic contributions and industrial praxis
in that while the former focus on merging languages on a source or meta-level
the latter successfully integrating the target representations. This pragmatic
approach is supported by proven techniques developed for integrating third
generation programming languages. Organisationally the challenge seems to be for
management to assign the right team { with the right skills { to the right task, a
parallel challenge to the challenge of applying the right tools to the right
problem [
In the case of setting up a simulation environment at Volvo Cars the
challenge is not just to integrate di erent modelling languages but also agreeing on
the same version of Simulink since di erent versions imply di erent properties
in the generated code. Here, the challenge is organisational due to the fact that
the developers want the newest features which enable new solutions while
management responsible for integration need to know that the new version is stable
before updating. Updating legacy models to comply with the newer versions can
be both a time consuming and an error-prone task. With external organisations
submitting their intellectual property in the form of human-readable models or
code the question also becomes an issue of trust { not a technical factor of how
to best compose two or more languages. How to organise an ecosystem [