Monthly Archives: Juli 2010

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:

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

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:

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.