A few days ago I posted a comment on Jim Whitehurst’s article, stating my opinion that his request to make mission critical application software of the ECUs is unrealistic. So does that mean that open source software has no future in automotive? Of course not. The software of an automotive company could be divided into the following categories:
- Business Software (e.g. SAP, Oracle, Web Servers)
- Development Tools (everything for the product lifecycle, i.e. requirements, design, implementation)
- Basic Software for ECUs (i.e. the “Operating System”)
- Application Software
Obviously, for the Business Software, the automotive industry is not too different from other industries. Open source alternatives exists and are in use (like Apache Web servers etc.) to some degree.
The development tools are experiencing an increase of open source software through the use of Eclipse. A number of OEMs, suppliers and tool vendors are using Eclipse as a platform for standard and company specific tool development. GMF, EMF, Xtext and others are widely accepted. The commercially reliable license of Eclipse is a strong factor for the adoption of the platform. And the commitment to Eclipse starts to pour back to the open source community: The new Sphinx project proposal is based on a code base that was developed by the Artop members.
Basic Software has not played a major role in open source yet. One factor being, that there was not a widely accepted standard before AUTOSAR (yes, there was OSEK, but AUTOSAR might bring more attention). Right now, there is no established open source code base for AUTOSAR, but with everything being standardized, this might start with simple modules.
Application Software (your driving assistance, dynamics, enginge control) etc. will still be considered an important setting and not be easily migrated to an open source model.
However, open sourcing application software would probably have a small effect on quality only. Improving the development tool chain is going to yield better results. And open source offers a lot for the tool chain.
Red Hat CEO Jim Whitehurst voices his opinion that open sourcing the embedded software in automobiles would significantly increase quality in an article published in business weekly. Being an advocate of open source myself, I still think Mr. Whitehurst hasn’t done the open source community a service, because he superficially claims that open sourcing software would solve problems, without addressing any of the issues that arise:
- The business model: The user functions that differentiate one car from another largely depend on software. Especially in the premium segment, introducing new functionality is one of the key factors. If you introduce a new function, like night vision, you do not want to give away your investments. This is one of the core parts of the business. Mr. Whitehurst does not show explain how a new business model for the industry could look like.
- Knowledge: Software functions in automotive are extremely complex and not only require know-how in physics, engineering but also in international requlations. How big is the community that could really understand these systems and contribute?
- Testing: Mr. Whitehurst cites successful examples of open source: Firefox, php, and others. But here’s the catch: Those systems can be build and tested by anyone with a PC. Embedded software is inherently different. ECUs usually have specific hardware (different sensors) etc. To really test a system, you need a lot of hardware (including sensors and actors), you have to go to Norway in winter for cold weather testing and Dubai in summer for hot weather testing. HIL testing is necessary. This greatly reduces the target audience.
In addition, no OEM can allow you to reprogram your car and drive it on public streets. - MBSE: Physical functions are often designed with tools like Mathlab / Simulink or Ascet / SD. Open Sourcing the generated code from those tools is next to useless. So you’d have to open source the models, which require tools with expensive licenses to work with.
- Safety: Non of the quoted open source software is safety-relevant (how many people die if your Firefox browser crashes and is not available for 3 seconds?). Safety relevant software has to be carefully designed, for moral and for legal reasons. So where are the references to successful open source projects with SIL (safety-integrity-levels) requirements?
- Supplier: Requesting that “Toyota should open source its software” neglects the situation of IP rights. Software is usually only written in small parts by the car manufacturers (OEM) but largely by suppliers of ECUs (e.g. Bosch, Denso).
- Kaizen and Open Source: Whitehurst implies that Kaizen for software means Open Source and that Toyota should transfer its principles of Kaizen to software. If that is so, where can we download the specifications of Toyota motors, constructions plans etc.? Kaizen obvioulsy does not mean open sourcing anything.
The article quotes “Toyota acknowledged that a software glitch was to blame for braking problems in 2010 Prius vehicles, and the company changed its braking system software in January to address the problem.” However, if you read this article by CNN, you will see that the braking problem relates to the software for hybrid systems, which are considerably different from traditional braking. There is no proof, that this problem could have been avoided by open source.
Mrz 10
12
Xtext, BNF, Marte and MSCs
Currently we are doing some work on the specification of non-functional properties (such as timing) in the ITEA2 VERDE project. In VERDE, the UML profile MARTE plays a major role. MARTE has a BNF-based Value Specification Language that can be used to specify, amongst other things, timing like The VSL is specified in typical BNF notation
<value-specification> ::= <literal> | <enum-specification> | <interval> |
<collection> | <tuple> | <choice> | <expression> |
<time-expression> | <obs-call-expression>
Creating a Xtext grammar is very easy, but re-typing and manually transforming from BNF to Xtext is boring. Obviously, with a Xtext grammar for BNF, we could easily transform the MARTE BNF into a MARTE Xtext grammar and work with that. The first shot is a grammar like
grammar de.itemis.verde.Bnf with org.eclipse.xtext.common.Terminals
generate bnf “http://www.itemis.de/verde/Bnf”
Model:
(rules+=Rule)*;
Rule : “<”name=RULENAME”>” “::=” e=Expression ;
Expression :
el+=OredElement (“|” el+=OredElement)*;
OredElement:
(terms+=Term)+;
//LineEnd: EOL+;
//List: Term | (t=Term l=List);
Term: o=OptionalExp | l=ListExp | k=KeyConstr | r=RuleCall;
OptionalExp:Â Â Â “[" x=Expression "]” (mult?=”*”)?;
ListExp:Â “(” x=Expression “)” (plus?=”+”)? (mult?=”*”)? ;
KeyConstr:Â k+=Keyword (“..” k+=Keyword)? ;
Keyword:
text=STRING;
RuleCall:
“<”ref=[Rule|RULENAME]“>”;
terminal RULENAME : (‘a’..’z'|’A’..’Z'|’-') (‘a’..’z'|’A’..’Z'|’-'|’0′..’9′)* ;
An additional Xpand templates generates a nice Xtext grammar. Now we just have to get rid of the left recursion. As there is an algorithm for that too, we are thinking of putting that algorithm in the generator.
Another application could be the generation of a parser for the textual format for message sequence charts, as this definition is also available in BNF.
Mrz 10
11
Another kind of domain specific
On the lighter side of DSLs, Xtext 0.8M5 fixes a bug with unicode characters. It is now possible to use Unicode characters in literals of your grammar.
So the example grammar of new Xtext Projects in Chinese could look like this:
Of course, content assist and outline are fully supported:
All you have to do is to set Eclipse to use UTF-8 for the workspace through Window->Preferences->General->Workspace.
And, with a little overloading of the ID terminal, like this:
terminal ID :
‘^’?(‘a’..’z'|’A’..’Z'|’_'|’一’..’é¾¥’) (‘a’..’z'|’A’..’Z'|’_'|’0′..’9′|’一’..’é¾¥’)* ;
You can even use chinese characters as IDs:
Jan 10
29
Scoping with Xtext/TMF 0.8
Usually I hate it when APIs break. TMF 0.8 introduces a different scoping API than Xtext 0.7. It took me a while to figure out. So I’ll show the changes below:
Component :
   "component" name = ID "{"
   (ports+=Port)*
   "}";
Port :
   "port" dir=Direction name=ID ":" ref=[Interface|ID] ";"
   ;
enum Direction :
   IN="in" | OUT="out";
Instance:
   "instance" name=ID ":" type=[Component|ID] ";"
   ;
Connection:
   "connect" in=[Instance|ID]"."p=[Port|ID] "->" in2=[Instance|ID]"."p2=[Port|ID] ";"
   ;
The default code completion will traverse all defined Ports for the references p and p2 in the Connection rule. A better behaviour would be:
- Show only the ports in the instances (in, in2)
- For p, show only “OUT”-Ports, for p2, show only “IN”-ports.
To do this, we need to define methods in a class derived from AbstractDeclarativeScopeProvider. The method names follow the signature scope_<rule>_<element>, so the the old code fragment for was:
public class AutomotiveDSLScopeProvider extends AbstractDeclarativeScopeProvider {
   IScope scope_Connection_p2(Connection ctx, EReference ref)
   {
      if(ctx.getIn2() == null )
         return IScope.NULLSCOPE;
      else
         return new SimpleScope(IScope.NULLSCOPE, getRPorts(ctx.getIn2().getType()));
   }
   IScope scope_Connection_p(Connection ctx, EReference ref)
   {
      if(ctx.getIn() == null )
         return IScope.NULLSCOPE;
      else
         return new SimpleScope(IScope.NULLSCOPE, getPPorts(ctx.getIn().getType()));
   }
   private Iterable<IScopedElement> getPPorts(Component clazz) {
      List<IScopedElement> result = new ArrayList<IScopedElement>();
      for (Port f : clazz.getPorts())
         if (f instanceof Port && f.getDir() == Direction.OUT)
            result.add(ScopedElement.create(f.getName(), f,"("));
      return result;
   }
   private Iterable<IScopedElement> getRPorts(Component clazz) {
      List<IScopedElement> result = new ArrayList<IScopedElement>();
      for (Port f : clazz.getPorts())
         if (f instanceof Port && f.getDir() == Direction.IN)
            result.add(ScopedElement.create(f.getName(), f));
      return result;
   }
}
One of the important changes that I use different imports, because some are deprecated and some are generally nice to use. Newly introduced are:
import static org.eclipse.xtext.scoping.Scopes.*;
for helpful functions and
import com.google.common.base.Predicate;
import com.google.common.collect.Iterables;
import com.google.inject.Inject;
for working with lists. So the new code looks like this:
public class AutomotiveDSLScopeProvider extends AbstractDeclarativeScopeProvider {
protected Predicate<Port> pPortPred = new Predicate<Port>(){
public boolean apply(Port input) { return input.getDir() == Direction.OUT ; }
};
protected Predicate<Port> rPortPred = new Predicate<Port>(){
public boolean apply(Port input) { return input.getDir() == Direction.IN ; }
};
public IScope scope_Connection_p2(Connection ctx, EReference eRef)
{
EList<Port> features = ctx.getIn2().getType().getPorts();
return scopeFor(Iterables.filter(features,rPortPred));
}
public IScope scope_Connection_p(Connection ctx, EReference eRef)
{
EList<Port> features = ctx.getIn2().getType().getPorts();
return scopeFor(Iterables.filter(features,pPortPred));
}
}
Note that the scopeFor helper takes away the work of creating the newly introduced IEObjectDescription that I struggled with at first. Once you know how, migrating seems not too bad.
Posted in MDSD von .
Dez 09
16
MDSD Screencasts
Some of the screencasts explaining an MDSD showcase have just been published on my youtube site.
The introductory screencast to our showcase:
The screencast explaining Xtext in our showcase (in 3 parts):
And in addition, Markus Völter’s screencast explaining Variants, Feature Modeling and Model Transformation:
Enjoy!
Okt 09
20
Troubleshooting Web’N'Walk
Letzte Woche hat mein Web’N'Walk Stick von t-mobile aufgehört zu arbeiten. Auf Grund irgendeiner anderen Software waren wohl die Treiber zerschossen. Leider konnte ich bei t-mobile keinen Download für neue Treiber finden.
Mit ein bisschen Recherche fand ich folgende Lösung: Treiber für meinen Stick gibt’s bei www.option.com. Neu installiert, jetzt tut wieder alles.
Sep 09
27
UML, good or bad?
Via Adriano Comai I stumbled upon Ivar Jacobson’s article “Taking the temperature of UML” , an interesting view of one of UML founders on the UML. One of the important quotes is:
Still, UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call the “Essential†UML. We must make UML smarter to use.
There is a strong point in UML being too big. I have been following UML since its inception, having worked 10 years on one of the first UML tools, Software Through Pictures. Over the time, I have more and more been favouring (textual) DSLs. One of the reasons are the intrinsic problems of graphical modelling, so one of the quotes I cannot really agree to:
There are a number of good and easy to use tools.
The situation has gotten much better, but graphical modeling tools are very complex to get right and I’d support the statement on one of the speakers on the german Architektour podcast that there are few tools that I really like, only tools that I dislike less. However, in project settings, there might be some influencing factors that make UML and UML tooling is the best solution. If you understand german, most of the arguments pro and con UML that I’d use are mentioned on the Architektour podcast.
I like Pedro J. Molina’s article in his post “Using the 20% of UML”.
So I don’t think an “Essential UML” would be the right way to go. Time is better invested to find the right DSL for your domain.
I am happy that the talk that Markus Völter and I submitted for the Eclipse Summit Europe 2009 has been accepted.
Wednesday, 14:20, 40 minutes | Room 6
Model driven development and code generation is relatively widespread in the development of embedded systems. However, usually, large and expensive UML-based real-time modeling tools are used, typically in conjunction with their own runtime environment. To make this approach scale down to smaller, more agile environments, a more lightweight and flexible approach is needed. In this talk, we show how the Textual Modeling Framework, the Xpand code generation engine and a couple of utilities for managing product line variability in models can be used to develop embedded systems. Architects develop their own domain specific language and code generator, to make sure the abstractions and the generated code fit their needs on the target platform. The talk uses a minimum of slides and is based mostly on a realistic example, showing the DSL, the code generator and the way we’ve built it. — Note: the attached slides are based on a related talk. They will be adapted slightly to fit the proposed session better. But the provide a realistic estimate for style, amount and content.
http://www.eclipsecon.org/summiteurope2009/sessions?id=854
I was just trying to set up a M2M transformation from a textual DSL to UML2 with the Galileo release. Obviously, a lot of paths have changed from oAW to Galileo, so this needs some work. However, I had an error, that annoyed me. In the editor, everything was fine, no errors, but when running the workflow, the transformation had errors like:
EvaluationException : Couldn't find operation 'setName(String)' for uml::Class. Â Â Â torcssim::common::m2uml.ext[438,20] on line 23 'this.setName(c.name)' Â Â Â torcssim::common::m2uml.ext[315,16] on line 13 'x.components.c()'Â Â Â Â Â Â nofile[0,23] on line 1 'toModel(model,umlmodel)'
It could not cast from an Xtend String to an UML String. The solution is in adding the meta-model to the component:
 <component class="org.eclipse.xtend.XtendComponent">     <metaModel id="mm" class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"/>     <metaModel class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/>     <invoke value="torcssim::common::m2uml::toModel(model,umlmodel)"/>     <outputSlot value="transformedUMLModel"/>    </component>
Which is quite obvious when you have done it once, but if you try to set it up the first time, it can cost you quite some time. Especially, when everything looks good in the editor.