Relocation

Posted on by
Reply

The itemis south branch has been operating out of Pforzheim (which is 50 kms west of Stuttgart) for several years and we are really having nice offices in a good environment here. However, for a number of reasons, we feel that there are a number of factors that made us re-evaluate the Pforzheim location:

  • itemis is providing services to companies for MDSD in several domains. One domain is “complex technical systems”, which includes automotive / embedded. Several of our customers here in the south of Germany are obviously based in Stuttgart.
  • itemis is growing. We find it easier to find new talent for our Stuttgart office.
  • itemis is member of several consortia (AUTOSAR, Genivi) and research projects (VERDE, Q-Impress,etc.). Hosting meetings in Stuttgart will be more convenient for our project partners, that come from all over Europe.
  • itemis has its main office in Lünen near Dortmund. There is a great train connection from Stuttgart to Dortmund (3,5 hours).

All of this factors brought us to the decision to fuse our small Stuttgart office with the Pforzheim office in a new location in Stuttgart. Further factors where:

  • the location should be easily accessible from both the main station and the airport for guests, colleagues and commuters (basically no changing trains from those stops, more than one public transports stopping near the office)
  • the location should be easily accessible for our commuters from Pforzheim (i.e. a highway exit in the south west of Stuttgart)
  • the location should allow for growth
  • the location should have a bright atmosphere
  • food, good food. Good lunch is a prerequisite for a good afternoon.

We found all that in the Stuttgart Engineering Park STEP and I am looking forward to us opening the new office and growing further in January.

Integrating the AUTOSAR tool chain with Eclipse based model transformations

Posted on by
Reply

Integrating the AUTOSAR tool chain with Eclipse based model transformations

Andreas Graf1,Markus Völter2

1: itemis GmbH, Blücherstr. 32, 75177 Pforzheim, Germany

2: independent/itemis GmbH, Hohnerstr. 25, 70469 Stuttgart, Germany

This paper has been presented and published at ERTS2 2010

Extended Abstract for Application:

Keywords: AUTOSAR, Eclipse, Open Source, model transformation, Artop, Model Driven Engineering, AUTOSAR tool chain, software development process, AUTOSAR migration, automotive software, standardization, Engineering tools integration and interoperability, Open source, open systems.

1. Introduction

AUTOSAR is establishing itself as a prominent standard in automotive systems and is expected to significantly improve software architecture and the software development processes. However, the introduction of AUTOSAR also poses some challenges.

AUTOSAR only defines part of the development process, it does not specify how to interface tools in preceding process steps (such as functional design or requirements engineering) and to subsequent steps (such as testing or the actual implementation of the software).

In addition, AUTOSAR currently does not cover all aspects of automotive software. AUTOSAR software needs to communicate with non-AUTOSAR software, for example in the infotainment domain or even with off-board software.


In addition to these conceptual challenges, the availability of tools can be a challenge, too. Similar to the early phase of UML, AUTOSAR tools are rather new and immature, and experience with those tools is not widespread. Tool features might be lacking and the integration of AUTOSAR tools into a company’s overall tool chain will definitely not be provided out of the box by an off-the-shelf tool. It needs customization.

The different steps in the AUTOSAR methodology might be addressed by different AUTOSAR tools from different vendors. Those tools need to interact with each other, increasing increases the need for an open approach that allows for customization and extension.

2. Scope of the paper

In this paper, we discuss a number of examples of the challenges above. The paper shows how these challenges can be alleviated by Eclipse based tools.

Eclipse has established itself as an industrial strength development tool in industries that develop complex systems, such as aerospace and automotive. OEMs, first-tiers and suppliers already successfully use it for software development and as a rich and mature tooling platform. It can be seen as a platform for domain specific extensions that can be used out-of-the box (e.g. the C programming IDE “CDT”) as well as a platform for additional tools.

The open nature of the Eclipse platform allows for the integration of applications and project specific extensions.

With Eclipse’s latest Galileo release, several mature tools for model-driven software development (MDSD) have become available. These provide a flexible and low-cost set of tools for bridging the gaps in existing AUTOSAR tool chains.

The paper is structured as follows: We first introduce the AUTOSAR tool platform Artop and a number of open source Eclipse Modeling tools and explain their role in model driven development. We then show example challenges in the integration of an AUTOSAR tool chain and sketch solutions for these challenges based on the Eclipse based tools introduced.

3. Tools

In this paper, we look at Eclipse-based tools for model-driven software development. Eclipse is an open source project started by IBM a couple of years ago. Initially Eclipse was a Java development environment. However, from the start, Eclipse has been architected to be extendable in significant ways. Over time, a number of additional projects have been initiated as part of the Eclipse platform; among them the Eclipse Modeling project.

The Eclipse Modeling project is a collection of frameworks and tools for model driven development. In sum, they provide a wide range of solutions for various aspects of model driven development, from language definition to editor construction to code generation as well as model verification and validation.

This section introduces some of the tools from Eclipse Modeling. Specifically, we suggest those tools as a basis for integrating an AUTOSAR tool chain.

EMF

EMF, the Eclipse Modeling Framework, forms the basis for all Eclipse Modeling tools. At its core, it provides the Ecore meta meta  model, a formalism for defining the abstract syntax of modeling languages. EMF comes with a set of related frameworks and tools for validation, query, persistence, and model transactions.

Xpand

Xpand is a framework for code generation (in fact, you can generate any kind of textual artifact such as configuration files or documentation as well). It processes models based on languages defined with EMF. The Xpand language itself is quite sophisticated in the sense that it contains a powerful expression language for querying and traversing models. It also supports polymorphism and aspects for code generation templates, making sure that nontrivial code generators remain maintainable.

Xtend

Xtend is used for transforming models into other models, for modifying existing models before they are fed into a code generator, as well as for implementing simple helper functions that are used as part of code generation templates.

Check

Check is used for validating models. Constraints are expressed in the constraints Check language (which embeds the same OCL-like expression language used in Xpand and Xtend). The constraints are then evaluated either in real time in the editors when creating models or as part of model transformation and code generation workflows.

Xtext

Xtext is a framework for defining textual domain specific languages. Based on a grammar definition, the Xtext tooling generates a parser, an EMF meta-model, as well as an editor for the language defined by the grammar. The editor provides all the features known from current IDE’s: code completion, syntax highlighting, folding, customizable outline views, go-to definition and find references, etc. Using Xtext, the effort of defining languages and providing editor support on a level that makes using that language productive and comfortable becomes significantly simpler.

GMF

GMF supports the construction of graphical editors (box and line style) for existing EMF meta-models. Using this framework, you can define graphical notations for your own languages.

Integration of the tools

Using the above mentioned tools together results in a complete toolset for model driven development. You define your meta-models using EMF, then you add a graphical or textual notation using GMF or Xtext, you use check for validating models, and finally, you can use Xtend and Xpand to transform the models created with your graphical or textual editors into other models or text.

An additional project, the modeling workflow engine, is used to orchestrate the processing of models. It provides facilities for loading models from files and supplying them to validation, transformation, and code generation components.

Artop

One of the fundamental motivations of AUTOSAR is to increase the reuse of software within the car. Transferring this motivation to the AUTOSAR authoring tools is a logical step. This motivation drives the Artop initiative.

The AUTOSAR Tool Platform (Artop) is an implementation of common base functionality for AUTOSAR development tools. Artop uses many of the above mentioned frameworks to provide specific base functionalities for creating AUTOSAR tools. This includes a complete implementation of the AUTOSAR meta-model in the form of an Ecore model, an extensible validation engine for checking AUTOSAR specific and even project-specific constraints, a sophisticated workspace management that takes into account AUTOSAR’s way of storing models and lots more.

Artop is developed by the Artop User Group, a group of AUTOSAR members and partners and uses Eclipse not only as its technical platform but also uses a similar community approach to develop the software. Artop is open to any AUTOSAR member or partner.

Sphinx

The Sphinx project proposal [Sph2010] is a proposal for a new Eclipse Model Development Tools (MDT) subproject.

While developing Artop a lot of functionalities were developed, that had their origins in the use of AUTOSAR, but were not specific to AUTOSAR at all. Similar functionalities were also required in other industries than the automotive domain, like avionics.

The goal of the Sphinx proposal is to remove these features from the Artop platform and rather develop them in a larger community within the Sphinx project.

4. Bridging the gaps

Based on these tools, there are two basic types of tool integration: A tight integration on the Eclipse platform and a looser coupling through data exchange formats.

The tight integration allows tools that conform to the Eclipse architecture to be integrated within one application. The user does not have to switch between different applications, because he sees an integrated development environment.

However, existing tools used by projects might not be based on Eclipse. By making use of the Eclipse modeling tools, a loose integration is still possible through data import and export.

5. Challenges and Solutions

In this section we show how to use the aforementioned tools to address a number of challenges in the integration of an AUTOSAR tool chain.

To describe the relevant AUTOSAR models, we will introduce a textual description of AUTOSAR models called ARText. ARText is based on Xtext and an early implementation is available through the Artop distribution. This language is used to illustrate AUTOSAR models used in the examples, since it is much more concise than a graphical notation. Here is an example of a definition of a sensor component with an interface in ARText format:

interface senderReceiver cardata {

data int32 speed

}

component atomic Sensor {

ports {

sender X provides cardata

}

}

Model-to-Model-Transformations and Model-to-Text-Transformations are shown as examples in the solutions to the challenges. The code fragments of the transformation are for illustration only. Real transformations might include additional code.

Adding AUTOSAR Import / Export to existing tools

Challenge: All tools within the AUTOSAR tool chain have to be able to read / write data in the AUTOSAR XML format. The AUTOSAR XML-format is a complex data exchange format. Adding reading / writing functionality to an existing application requires significant effort. If every tool re-implements the XML functionality, the end user basically pays several times for the development of a non-differentiating feature. The cost and time can be significantly reused by making use of Artop and the Eclipse modeling tools.

Figure 1 – XML Readers and Writers are a redundant functionality in the tool chain.

Solution: Artop provides capabilities to read and write the AUTOSAR XML formats to and from the Eclipse EMF. Using model transformations, AUTOSAR models can be converted to the native format of existing tools.

Figure 2 – Integrating non-AUTOSAR tools by model transformation

For the example, a transformation of the AUTOSAR model into a CSV (Comma-Separated-Value)-file is given. CSV is a common file format that can be read by various spread sheet and database tools. Each line of the output should contain a software component name and information about the ports of that software component. A Xpand template could be similar to the template shown in Fragment 1.

Code Fragment 1 – M2T of AUTOSAR into .csv

Code Fragment 2 – CSV Result

The first line of the output file contains the component of the short example given in the introduction with the specification of the provided part. The second line shows an additional software component to illustrate the structure of the output file. Any output file in a textual format can be generated by Xpand.

Integration of Behavioral Models

Challenge: AUTOSAR explicitly provides no means for the specification of the behavior (program logic) of software. In model bases software development, a number of modeling approaches are well established (such as state machines or dataflow modeling). However, AUTOSAR does not specify a mapping to behavioral modeling paradigms. The linking and synchronization between with artifacts in other modeling tools is not defined.

Solution: Use model transformations to synchronize the AUTOSAR model with a behavioral model. This helps to avoid redundant modeling of elements in more than one tool and manual synchronization. The exemplary solution links AUTOSAR models with UML state machines.

The meta-model elements of AUTOSAR and the state machine have to be mapped. A state machine needs to react to data being received. For this solution, we map AUTOSAR data elements to state machine triggers. Based on this mapping, a model-to-model-transformation generates the skeleton of a state machine and infers the required events / triggers from the AUTOSAR specification.

Code Fragment 3 – M2M of AUTOSAR into UML state machines

The code fragment generates a state machine for every software component and to keep the models synchronized, adds a trigger for each data element of required interfaces (i.e. incoming data).

Figure 3 – AUTOSAR Data Element as triggers in state machines

Comfortable Editing of Large models

Challenge: Creating complex models with graphical modeling tools often is a time-consuming task, since the creation of new model elements involve a lot of mouse movements and switching between keyboard and mouse.

Solution: Textual domain specific languages are an established approach to create a user-friendly modeling environment. A comfortable environment with syntax highlighting, code completion and navigation functionality allows the user to quickly create models without the need for time-consuming context switches between mouse and keyboard  [ARText2009]. Additionally, textual formats successfully scale to large projects and are also suited to distributed development environments. This is due to the format taking advantage of the well established textual tools and infrastructure supporting this environment. For example, configuration, source, change and version control. Support for these functions is integral for an effective distributed development environment.

With ARText the Artop community provides an environment for textual languages based on AUTOSAR. It defines and implements a textual language to describe AUTOSAR models. The framework is based upon Xtext which gives access to rich features for textual languages like syntax-highlighting and code-completion. The textual notation used in this document is the ARText notation.

Developers who are more inclined to textual formats will benefit from a less steep learning curve when developing AUTOSAR models with ARText.

Project Specific Code generation

Challenge: Existing tools might not be prepared for AUTOSAR-conforming code generation. Manual post processing of the code is necessary.

Solution: Create AUTOSAR conforming code by using customized generation templates based on Xpand.

For the exemplary integration of open-source state machine modeling / simulation, the Yakindu tool generation has been made AUTOSAR conforming.

The state machine for terminal control

Figure 4 – State Machine as input to the generation.

can be transformed into AUTOSAR compliant code that uses the RTE as an interface to get notified of incoming transition triggers and reacts by sending data through the RTE.

Migrating Legacy Models to AUTOSAR

Challenge: Migrate existing component models to AUTOSAR. Before the introduction of AUTOSAR, projects often modeled the software architecture with other notations (e.g. UML). These models have to be migrated to AUTOSAR.

Solution: Load the models into Eclipse and transform them to AUTOSAR. Most UML2 should have a XMI-conforming export. These models are loaded into a UML2-EMF model and subsequently transformed to Artop models directly by Xtend or to textual representations like ARText.

Suppose that every class in a UML model should be transformed into an AUTOSAR software component. The following Xtend transformation will perform this transformation.

Code Fragment 4 – M2M of UML to AUTOSAR

The second create function will create an AUTOSAR package in the destination model and call the transformation for every class in the UML model. The semantics of the class to component transformation is specified in the third create statement. Here it is a simply copying of the name.

Generating RTE for non-AUTOSAR Basic SW

Challenge: Implement an AUTOSAR RTE on platforms that have no AUTOSAR Basic Software available. One of the suggested migration strategies to AUTOSAR ECUs is the use of legacy BSW with AUTOSAR conforming application layer as a first step [AR2010]. However, COTS RTE generators cannot be used, since they usually do not support project specific legacy basic software.

Solution: Use Xpand to generate a RTE that conforms the API for the application software and interfaces to the platform specific basic software. Supposing, that a communication call in the legacy software would have the signature “void Legacy_SendCall(…)”, a RTE that makes use of this generation can be generated by a code fragment like:

Code Fragment 5 – M2M of UML to AUTOSAR

6. Conclusion

In the paper we showed some of today’s recurrent challenges in tools and described the need for more integrated tool chains. Challenges in the integration of an AUTOSAR tool chain can be solved by the use of inexpensive Eclipse based tooling. An open platform is the precondition for an integrated tool chain. The solutions shown in this paper have been applied in various projects.

4. References:

[Sph2010] Sphinx project proposal, http://www.eclipse.org/proposals/sphinx/

[ARText2009] S. Benz, D. Wong. “ARText – Driving Developments with Xtext“, http://www.slideshare.net/sebastianbenz/artext-driving-developments-with-xtext

[AR2010] S. Fürst et al., “AUTOSAR – Migration and Advantages of an Industry-Wide Standard“. Proceedings of the VDA technical Congress 2010

Visual CV

Posted on by
Reply

Just when I was thinking on how to replace the bullet point hell for introducing my CV vor an upcoming talk I came across a TED talk by David McCandless (http://www.ted.com/talks/david_mccandless_the_beauty_of_data_visualization.html). He provides a slide with colored bars for his CV which I consider visually fresh. So I decided to try one with Excel and with a little trick these can be made rather easily:

Obviously the first steps are to fill in your data with numbers reflecting the intensity of topics (I used 1-5). You can then use the “conditional formatting -> color scales” to get the formatting right. However, at this points, the actual data will still be in the cells cluttering the view.

Just use the “cell formatting->numbers” and pick “user defined” and enter a blank in the entry field. The numbers of the cells will disappear from view, but if you select a cell, you will still be able to edit it in the formula entry box of excel.

Requirements Traceability for Eclipse

Posted on by
2

Within the publically funded research project VERDE we are implementing not only an Eclipse-based ReqIF based editor as outline in a previous blog post, but also a traceability solution, since requirements alone would be moot.

There are some approaches to this in Eclipse already. The EDONA project imports requirements into a UML/SysML model profile in Topcased and does some tracing in the model. However, we are going for a more generic solution, since we want to trace elements from models that may not provide extension mechanisms like UML/SysML.

Our traceability information has to be stored outside of the models that we want to trace. In addition, we would like to be able to trace non-EMF “items” like source code, too.

So the approach is to introduce a generic traceability models that stores URI of the source and target “items” together with some metadata. The exact format of the URI can depend on the semantics of the “items”, but a generic implementation for EMF is provided. We plan to use this to trace requirements to AUTOSAR elements, UML elements etc.

A generic EMF based traceability solution, not only for requirements but for any artefact.

The generic implementation of the User Interface allows you to select EMF model elements and to trace these. It is then possible to add specific plugins to improve usability (e.g. add drag-and-drop requirements assignment to UML).

Ah, yes, it will be open source.

Generic UI for traceability, integrated in Artop (AUTOSAR).

CDT and structured analysis / Misra-C

Posted on by
5

MDSD is one way to improve quality and speed in software development. However, not all code in a system will be generated. There is usually a certain amount of code that is still handcoded. Manually written code is more error-prone, especially when you use languages that give you a high degree of freedom – such as C, which is still one of the most important languages in embedded systems. To prevent some of the pitfalls that C might have, especially for safety-relevant systems, programming guidelines are usually introduced. One of the best known set of guidelines is the Misra-C specification, which has its roots in the automotive industry.

It has several rules that intend to reduce ambiguities (it requires {} around the if/else-clauses), to avoid memory-related problems (no use of recursive function calls, no malloc) and things that make code hard to maintain (no more than two level of pointer indirection – **x is OK, ***x is not).

Obviously, this needs to be checked, and there is a number of commercial tools available that do this, most often as a command-line tool. However, Eclipse provides the CODAN framework, which makes structured analysis (and writing e.g. a Misra checker) much easier. It also has the advantage, that the analysis is done in the IDE, during coding and no build cycle is necessary. In a short time, I have implemented the following Misra-checks:

M2.2, M2.3

M12.9,M12.10

M14.8,M14.9,M14.10

M7.1

(sorry for the numbers, Misra has a copyright that does not allow you to freely reproduce their check descriptions). Some of these checks took only minutes to write, once you get to know the framework. Here is a screenshot of M14.8 (if, while, etc… have to be followed by {} )

Note the error markers.

I will add more checks when I have time. However, from the Miscra-licensing, it seems not possible to release it as open source. However, if you are interested, contact me and we could discuss.

Eclipse Automotive Industry Working Group Invitation

Posted on by
Reply

The Eclipse Automotive Industry Working Group is meeting again next Monday at Kugler-Maag offices in Kornwestheim near Stuttgart. The Automotive IWG defines its goals as:

  • To provide an infrastructure for tool development required by the automotive industry
  • To address and support the needs for the whole automotive software development cycle
  • To avoid that the same non-competitive basic tool functionality is redeveloped over and over again
  • To join forces and meet current and future requirements in terms of tool runtime performance and memory consumption

We started with a high number of participants in 2008, then 2009 came and meeting participation declined due to budget cuts in the industry. It is good to see that we are gaining drive again. The recent meetings were attended by major 1st tiers, an OEM (with others expressing interest, but still being constrained), the Eclipse Foundation, itemis, Geensys and Kugler-Maag (have I forgotten anyone).

We invite 1st-tiers and OEMs and other companies that see Eclipse as an important factor for their tooling to attend the working group (again, if you were there at 2008). Contact me or Ralph Müller at the Eclipse Foundation if you would like to attend. You can also use the web page above for registering.

Natural Language and DSLs

Posted on by
1

A year ago I had blogged about Inform 7, an interesting DSL for the implementation of interactive fiction. I had briefly explored it, but didn’t do much more, because some of the concepts made it hard to use for my purposes (e.g. “relations” could only be defined between instances of objects, not classes. So you needed a lot of workarounds). However, just recently the developers released a new version that removes several limitations.

I happen to come back to look at the DSL, if only for inspiration on how you can find notations that seem natural and yet are formal.  Inform 7

  • wants describe a “world” in an executable way
  • expects its users to be literary inclined, not programming geeks.

These goals are obviously similar to the use of DSLs. An example of how a description of a physical system could look like can be found in the examples:

Especially the first three lines show how a physical system with rules can be described in (almost) natural language. And it can actually be executed. This is a transcript of the session:

Of course, we’d probably not describe lead pigs put components of cars and satellites ….

Another interesting feature is the specification of tabular data. Again from the docs:

Table 2.1 – Selected Elements

Element Symbol Atomic number Atomic weight
“Hydrogen” “H” 1 1
“Iron” “Fe” 26 56
“Zinc” “Zn” 30 65
“Uranium” “U” 92 238

And the access to the table:

symbol in row 3 of the Table of Selected Elements

It will be interesting to see, if notations like this will establish themselves more and more.

AUTOSAR, CDT and static analysis

Posted on by
1

The Eclipse release Helios brought a lot of new features. A lot of attention on the website is put on Xtext or Acceleo. But for the embedded world, a nice new feature has found its way into CDT: The subproject Codan provides a framework for static analysis of the C/C++ code directly in the editor.  Provided are several examples. One is checking for an assignment in a condition:

The great benefit of, again Eclipse / Plugins, is the extension concept. I have just added another check, that does static analysis for AUTOSAR naming conventions while editing. The AUTOSAR RTE (Run time environment) specification defines the structure API of the RTE (which is generated from an AUTOSAR model). The API differs from Software-component to software component. Example calls from the spec could be:

to find all ports of an interface type <i>, where P and R denote Provided or Required.

where <p> is the port name and <o> is the data element to be read.

With a few lines of code, I made Codan (i.e. CDT) learn that any function starting with “Rte_” should conform to the spec, and any other function is ignored by my static analysis. The programmer is immediately notified of incorrect API calls.

A short demo is attached below. There is plenty of ideas that come from this great (not so) little gem.

Requirements and Eclipse: RIF/ReqIF as Ecore (and with Xtext)

Posted on by
4

Within the VERDE project, itemis is working on the traceability of requirements based on the Eclipse platform. To be able to work with requirements, we have implemented an Ecore representation of the RIF/ReqIF requirements exchange format. RIF was developed by the German HIS Automotive and is now being standardized by the OMG under the new name “ReqIF“.

Nirmal has derived the Ecore format from the specification that is provided as an Enterprise Architect model. And of course we have combined this with textual DSLs. RIF allows you to model your own requirements structure (i.e. define requirement types, attributes and links). This can be done through the ecore editor and the GUI for the requirements is automatically generated during runtime. A possible structure could look like this:

The definition of this requirement structure is like this:

In our solution, you cannot only define natural language requirements, but through the integration of Xtext you can bring in more formal notations – be they standard or project specific. Of course, you get all the benefits of Xtext, like content assist, syntax highlighting etc. Here is a screenshot of the content assist in our small formal language.

Android, AUTOSAR and Xpand

Posted on by
Reply

Xtext 1.0.0 is scheduled for the Helios release and while I think that it is a great tool we shouldn’t miss the other apects of a toolchain that are crucial for MDSD: M2T, especially code generation. It is only with M2M and M2T that models show their full potential, since we can use automation. The front end does not necessarily have to be Xtext – In this example we are generating code for several platforms from Artop, the community source tool platform of AUTOSAR. Artop provides an EMF based implementation of the AUTOSAR metamodel (and much more) and is a perfect source for code generation.

In the AUTOSAR methodology, as described by the standard, a Run Time Environment (RTE) is generated from the model. The specification defines a C API that represents the RTE and all commercially availalbe tools implement this C specification. However, we use the AUTOSAR models to generate Java code for Android and specifications for business applications, too!

This is our showcase, that we present on fairs etc: A RC car chassis contains several ECUs. A sensor transmits data to a Gateway ECU. This ECU forwards the data both to a display (like your infotainment), but it also forwards this data to a server running a webserver from which it is transferred to mobile devices, like android phones. This is typical for the future challenges in automotive systems: The convergence of technologies from different domains.

Showcase - ECUs communicating with Web Services and Android

With manual coding, the code for accessing and transmitting the data would have been written several times independently, and changes would have been integrated the same way too. However, we have written Xpand templates for code generation, that not only generate to different RTEs for the in-car ECUs, but also generate code fragment for the Web-Service and the Android application. Adding new data (like rpm) to the transmitted information is supported by code generation, resulting in less manual changes and in higher quality at shorter development cycles.

Using Xpand to generate more than C from Artop

Eclipse technologies provide a great set of tools for leaving the trodden path of monolithic tools and implement efficient solutions for customer requirements.

Android application - basic data API is generate from AUTOSAR model