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.

• 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.

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:

1
2
3
4
5
6
7
8
9
10
11
12

"Lead Cuts Paper"
 
A weight is a kind of value. 10kg specifies a weight. Everything has a weight. A thing usually has weight 1kg.
 
A container has a weight called breaking strain. The breaking strain of a container is usually 50kg. Definition: A container is bursting if the total weight of things in it is greater than its breaking strain.
 
A lead pig, a feather, a silver coin and a paper bag are in a room called the Metallurgy Workshop. The paper bag is a container with breaking strain 2kg.  The lead pig has weight 50kg.
 
Every turn when a container (called the sack) held by someone visible (called the chump) is bursting:
 say "[The sack] splits and breaks under the weight! [if the player is the chump]You discard[otherwise][The chump] discards[end if] its ruined remains, looking miserably down at [the list of things in the sack] on the floor.";
 now all of the things in the sack are in the location;
 remove the sack from play.

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:

Lead Cuts Paper
An Interactive Fiction
Release 1 / Serial number 100707 / Inform 7 build 6E72 (I6/v6.31 lib 6/12N) SD
 
Metallurgy Workshop
You can see a lead pig, a feather, a silver coin and a paper bag (empty) here.
 
>get pig
Taken.
 
>get bag
Taken.
 
>put pig into bag
You put the lead pig into the paper bag.
 
The paper bag splits and breaks under the weight! You discard its ruined remains, looking miserably down at the lead pig on the floor.

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

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.

if (a=x) ....

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:

Rte_Ports_<i>_<P/R>(...)

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

Rte_Read_<p>_<o>(...)

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.

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.

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

I have created a short video to demo how the current nightly build of Papyrus supports the editing of ports nicely (Update: by the use of ANTLR, next versions will use Xtext, which is also based on ANTLE). If you choose to edit a port, you get a textual editor with syntax highlighting and content assist (and content assist knows about your UML model!)

Great job, Papyrus team!

Grab your nightly build at: https://build.eclipse.org/hudson/job/cbi-papyrus-0.7-nightly/

Soon coming: A blog entry about how we integrate Xtext to bring more formal notations into requirements engineering.

Standardized platforms are the solutions to increased development costs and quality problems in many areas of software development. In the automotive industry, platforms for the ECU Software have been defined within AUTOSAR and Genivi. OEMs and suppliers are thereby assured of reduced costs and improved quality by virtue of the standardized interfaces. Standardized platforms improve the quality of infrastructure components of software and pave way for more focus on the differentiating features. These factors are also advantageous during the application of a platform strategy in tool development.

Cost reduction using platforms

When considering the development tools in a  product development process, many similar features are developed anew by the tool manufacturers independently and with different technologies: data storage, user interfaces, connection to architecture tools and graphical editors are just some aspects of infrastructure. To illustrate the AUTOSAR tool chain is considered. AUTOSAR defines an XML interchange format in order to process the AUTOSAR descriptions beyond the tool boundaries. Each tool in the development chain can use the XML format for interchange and stores the AUTOSAR models in a specific representation in the memory. The processing steps of these sections of the development process are thus:

• Importing the existing models from the XML format into the internal format of the architecture tool and processing of the model
• Exporting the internal representation from the architecture tool into XML format
• Importing the XML format into the internal representation of the RTE generator and generation of the header files.
• Importing the XML format into the internal representation of the modelling tool in the internal format of the modelling tool and
• Generation of the code

Altogether three tools implement the functionality of importing the XML and at least one tool to save in XML format. Since these tools are developed by different companies, this functionality is implemented three times and paid for by the customer. The complexity of XML makes implementing different versions of AUTOSAR complex as well. However, this is not differentiated by the tools. Therefore, it can be predicted that there is also demand for re-use of the tool chain. Open source platforms offer this possibility. At this point, Eclipse can be of use in different scenarios:

• “Out of the box”: Eclipse provides many applications that can be used directly. This includes development environments for C and Java, but also for modelling according to UML, data mining and others.
• As basis for applications: Frameworks for data management, user interfaces, graphical editors, forms, web access etc. are part of the Eclipse platform. Projects can set up their development on these frameworks and reduce cost. There are additional platforms for certain industries (partly independent of Eclipse).  For example, in the automotive sector this is Artop, which is being driven by some AUTOSAR partners and provides reading, writing, and the management of AUTOSAR models.
• As integration platform: The common data model and  infrastructure enables a tool design in such a way that they are more closely meshed and tool gaps avoided.
• For project-specific functions:  Development departments can build specific features on this platform that are not provided by the tools.

Artop

The AUTOSAR Tool Platform (Artop) is an Eclipse-based implementation of basic functionality for AUTOSAR development tools. Artop and its source code are freely available for all AUTOSAR members and partners. itemis perceives Artop as a viable platform for development tools in the automotive sector and provides its technologies in the model-based software development as a contributing member to the project. itemis advises OEMs and tool developers in the development, adaptation and introduction of Eclipse-based and Artop-based tools.

ARText

AUTOSAR models for complete and partial systems can be of considerable sizes. The experience with building and managing such models show that graphical editors often reach their limits here. An efficient alternative is the modern specific textual languages that can be effectively created using comfortable editors. Studies show that the input of large models is much more ergonomic and faster because of the absence of constant switching between mouse and keyboard. Issues such as version control and model comparison, which still has not been satisfactorily resolved by graphical models, are easily resolved by textual models with the established tools from the source code management.  Thus, textual editors are much more cost-effective to implement and they are automatically generated to a large extent.

This concept is pursued and implemented in “ARText”, the sub-project of Artop. ARText is based on the core technology “Xtext” provided by itemis and is a comfortable editor for AUTOSAR models.

itemis supports the operation and adaptation of textual, domain-specific languages like ARText.

Picture: Mark Evens – istockphoto

It reflects the fact that Eclipse has established itself in the development tool chain of automotive software – in a domain that is traditionally rather conservative and cautious of open source software. Despite this cautioness, a lot of OEMs and 1-st tiers are already making use of Eclipse, but the notion of open source, community source and collaboration still raises questions in middle and upper management.

The membership of a major 1-st tier shows that it is feasible to use and contribute open source for tool development.

Information about Bosch’s activities can be found in this talk at OOP and this talk at ESE.

However, there is more activity in print. Having discovered a chinese websearch for magazine research (http://it.alljournals.cn/) I was interested in a little statistics and tracked the number of published articles on “model driven” (模型驱动).

Another keyword that yields a lot of result is MDA.  One of our main points of focus in European business, the use of domain specific languages is not yet a major subject in Chinese magazines. Searches result 2-3 hits in 2008 and 2009. It will be interesting to watch the future trends. The chinese already have produced one of the nicer UML tools based on Eclipse (www.trufun.net).