BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: AUTOSAR (Page 3 of 3)

USA II – The Falls.

And…. back…

Well not completely. Just sitting at the Delta Terminal in Detroit and waiting for the flight back to Schiphol Airport.
It has been a busy week with many customer visits, conf-calls and our Engineering@Scale event at the GM Heritage center.
Thanks for everyone that was there, it was cool. I think I have sent my presentation to everybody, if not… it is here: Pres – UML Modeling vs Coding E@S TD Detroit
The Willert Software Tools Movie that explains the use of tools in an Automotive field is here: Seamless Model-Based Development Process for Embedded Software Engineering

AUTOSAR

I had a cool demo with me, we (or actually Clemens….) managed to bring a first prototype of the RXF ArcCore RTE Connection. Still some “WorkToDo” but we have already a good working example where we can base the rest on. We are working in parallel on reading ARXML and extracting the relevant UML elements like ports, interfaces, variables, defines, types, runnable names, software components, so we can automate the process of using UML for the embedded automotive engineers. We are working to implement at least 2 use cases for the use of Rhapsody in Automotive environments:

UseCase 1 – Architecture

If you want to do your architectural work with Rhapsody, we want to offer a way to export stereotyped UML/SysML elements to an ARXML file. We’re currently not completely sure what we want to export, if you have ideas: SEND THEM!!

UseCase 2 – Behavior

You already have an architecture, you have defined SWC’s (or Runnables) and you want to implement (some of) them in Rhapsody. This is the UseCase that we are pursuing first (Because it is easier, we more or less know what to do, we have done it already for an older version of Rhapsody and an older version of AUTOSAR)

Niagara Falls

So. A brief overview of what we are working on. In 3 weeks I am back in the USA for more visits, AUTOSAR Conference and the IBM ICE Meeting.
This weekend we did a “round Lake Erie”. That takes you through Canada, Niagara Falls, Buffalo, Cleveland and back to Detroit. That was pretty cool, here are some pictures.

That’s it! Happy modeling with Rhapsody!
Walter van der Heiden (wvdheiden@willert.de)

 

Engineering@Scale Tech Day

Join us for Engineering@Scale Tech Day. Learn how new solutions and technologies are helping to lead the innovation agenda while addressing the complexity challenge in the automotive industry.

This event will focus on engineering systems and software development.  We will feature sessions around industry best practices and the core processes of requirements management, architecture design, collaboration, change and configuration management, test and quality management, product line engineering and variant management. Improve your skills, network and collaborate with industry experts.

What to expect:

  •  Keynote session by the American Center for Mobility
  •  Technical sessions for novices to experts, with topics ranging from:
    •  Scaling Agile to the Automotive Enterprise
    •  Convergence of MBSE and the Product Innovation Platform in Automotive
    •  Connected Product initiatives with Digital Twin and Digital Thread
    •  Improving your processes with Automotive SPICE
    •  Feature-based Product Line Engineering and Operations for the Automotive Enterprise
    •  Certifiable framework for AUTOSAR
    •  And more
  •  Networking Lunch (no charge)
  •  Plus, tour the spectacular automotive collection at the GM Heritage Center.

 Register today and share with a colleague!

General Motors Heritage Center
6400 Center Drive
Sterling Heights, MI 48312

Thursday, October 12, 2017 from 8:00 AM to 4:00 PM (EDT)

Bussum

Strategy

It’s not easy to have a good strategy for software. Things change so rapidly, what is important one day is totally forgotten a day later. Like AUTOSAR. There are 2 main streams, Classic and Adaptive.

Of course, as usual, we decide to concentrate on one and the next day customers start to ask about the other and vice versa.

So, no worries, we will do both!

For Adaptive we are preparing a Beagle Bone with Yocto Linux to get the first samples running, for Classic we have an STM Board that should work with a basic example.

We have already been doing a lot of work in getting a Classic AUTOSAR environment running. There were some examples with it but it still took us 2 days to get LED’s to blink on a board.

There is still a lot of “Voodoo power”involved in our opinion. Some stuff is totally incomprehensible for mere mortals as we are. It does not help when the documentation says: “The do a rebuild, just in case”…. Confidence sounds different.

What also _really_ surprised us is the size of the executable. We always thought that Automotive apps must be small. A blinking LED in 15k is not what I call small… Our UML generated stuff uses less than 1k for that. And we have trouble convincing people that the 1k is worth the increase in understandability.

During debugging we noticed lots of layered calls to abstract the Hardware. I think that is a great idea but we seriously doubt if any Automotive Companies is willing to pay the hardware price for that.

We also created Rhapsody models to generate code from that must be run in an AUTOSAR environment. We will then integrate the Rhapsody generated code with the AUTOSAR RTE generated code

Vacation

I will be on vacation the next 2 weeks. I will still be writing, no worries!

Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

AUTOSAR meeting Juli 2017 Paderborn

The planning was to have a more quiet week with less travelling. As usual, this did not work out well. As my good friend Bruce always says: The difference between theory and praxis is a lot larger in praxis than it is in theory. No problem, I’m used to that.

On Tuesday, at least that is what Clemens thought, we had a common AUTOSAR Meeting. We are AUTOSAR Premium Member (by proxy of Sodius) so we visit the meetings and we try to influence the process of the AUTOSAR specification.

So on Tuesday morning very early we drove from the apartment in Bückeburg to dSpace in Paderborn where the meeting was held.

There it turned out that Clemens made a tiny mistake. He assumed that all meetings had the same footprint during the week which was wrong. (As _I_ always say: Assumption is the mother of all f***-ups) So after a Tuesday full of very very in-depth AUTOSAR workgroup meetings (and a nice lunch, thanks dSpace!) we drove back to the apartment just to go up very early again on Wednesday to visit the meeting we wanted to visit….

Anyway… shit happens. This way Clemens and I had time to discuss the Willert AUTOSAR solutions. Basically there are 2 AUTOSAR solutions, Classic and Adaptive.

Classic is for targeted at smaller controllers and very static environments. Base is that many system information and software (SW-C, Software Component) information is captured in an XML structure (ARXML) Tools can read that structure and use the information in there to configure themselves and to export their own added information to other tools.

Adaptive is targeted at larger systems that have dynamic components. Base is a Linux environment with many specs for security. It will (amongst others) be used by ADAS (Advanced Driver Assistance Systems)

What does that has to do with us? Well, Rhapsody is a tool as well and it is, out of the box, capable of reading and writing these ARXML files. You can then add information and work with the provided information. We think, however, that this solution is not applicable and scalable enough for a lot of customers. So we visit the meetings and have access to the AUTOSAR information to be able to create our own simplified AUTOSAR profile. (Apple Style, or better: Jobs Style, keep it as simple as possible, hide the complex stuff, make it usable for everybody but also make the complex stuff still accessible for Guru’s)

What we basically do with Classic is that we import ARXML and convert it to UML Elements right away. In that way we can use “normal” UML to develop AUTOSAR SWC’s.

Adaptive is very new and in early stages of definition. So there is a lot to do for us in that area, not only in profiles and frameworks but we can do a lot there in Rhapsody modeling, at least that is what we think.

So in the next weeks we have a lot to do. Clemens and I will be cooperating in creating / improving the Willert AUTOSAR Solution!

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

 

Stuttgart 2 (The Sequel)

OK… Stuttgart again. I’m there so often that people think I live there… “Neigeschmeckt” they call it … (Something like “Tastes new” but ask a Schwabe if you want to be sure…..) To make it halfway bearable I’m with a different customer again. And I’m not alone, Joachim joins me for the training part and on Wednesday for support with our AUTOMOTIVE Rhapsody Model and later Andreas will join us on Wednesday for the MDSE part.

Yes correct, I’m with an Automotive customer again (what are the odds…) so a lot of extra constraints that are less important at non-automotive sites. They always use AUTOSAR, they never buy chips that have enough memory or enough power to do the job, often they have a very cheap CPU but there is only a CPU manufactured compiler (horrible, sometimes these don’t even fulfill ANSI-‘C’….) And they have time constraints that make all other projects look relaxed.

But this customer might use a bit different approach. At least a decent (although very expensive) compiler: Tasking and a decent (although complicated) CPU: Infineon TriCore. But they are determined to use MDSE and willing to put in the necessary effort.

It was a very nice week with very productive sessions. So I’m sure I will see a lot more of Stuttgart in the next months….

Back to Rhapsody. We had a new case, a customer from…. Stuttgart…., with a question I heard before. But that was a long time ago so i decided not to do a copy/paste solution but to dive into it and see if there were better solutions now. And there was…

The problem, or actually the question, was “How do I use Doxygen within Rhapsody”. Simple question. For those who do not know Doxygen: this is a system (Open source) to document C or C++ (amongst many others but these are the interesting for us)  source code. ( www.doxygen.org ) Of course it is Dutch, what else, and many developers use it.

You can document your source code with certain special comments, Doxygen will look for that and generate either an HTML or a LaTeX file. It can do stuff like generate call trees, looks pretty neat.

My first reaction, years ago, to this question was: why do you need to document your source code? It is generated, who cares? But that is too black and white. A lot of source code inside Rhapsody models can be documented and a Rhapsody model is, of course, way better as documentation but not everybody has Rhapsody! (We are working on that one…) So there is an actual use case for generating documentation from your partly generated source code. We even use Doxygen to document our RXF Framework!

But how do you do that? Simple way is to just use the “Description” field in Rhapsody, it will appear in the generated source code. But there are ways to make this more comfortable.

The “old” solution was to add some properties to your site.prp (sitec, sitecpp) But in modern time we can use profiles for that. So i decided to put the stuff into 2 profiles, one for C and one for C++.

A very nice feature of Rhapsody is that it has profiles. In these profiles you can do a lot of stuff that, once the profile is loaded in a model, has great influence on that model. You can set properties, define stereotypes and define tags. You can also define model elements that will be copied (and adapted!!) to your model and much more, I will write about that in a later Blog entry.

When you define tags in a profile and you assign these tags to a specific model element then (It’s magic!) the tags appear in all that elements in your complete model.

Another nice feature is that Rhapsody has a “Description Template” property for many model elements. In that property you can define what comment you want with that model element. You can use tags there ($TagName), the content of that tag will appear in the description. Quite cool eh?

So if you predefine some tags with Doxygen Standard Comments and you make a clever description template you can generate your source with the correct Doxygen Comments. The nice thing? I already did that for you, just download the model (8.1.5, if you need an older one: just ask, I’ll generate it for you, but you will owe me a beer…)

Download at: DoxyGen815

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

AUTOSAR meets Fjällbacka

The Willert AUTOSAR Team (Clemens Maas and me) regularly visit the AUTOSAR meetings. (See: AUTOSAR WebSite)

Since our successful introduction of Rhapsody @ Marquardt (See: Referenzstudie (German) ) we do more and more Automotive. The increase of software in cars is helping us to more and more Automotive customers that are all struggling to create their software in time and without (greater) errors.

AUTOSAR is the Automotive worlds standard to improve software development. It is an organisation that is founded by the major (mostly German) Car manufacturers. You can become a member and in that way cooperate and contribute to the software standard.

What does this have to do with Rhapsody? Good question…. I’d say: everything. With Rhapsody (UML or SysML) you can also improve your software quality, time to market, re-use and more. The combination of both worlds is, however, not really easy.

Many AUTOSAR artefacts look like UML or SysML artefacts but are different. Rhapsody is used to store everything in its own database (not a real database but it’s own file format) and not used to export stuff to cooperate with other tools like MatLab. This is something that is defined in AUTOSAR, the ARXML files that you exchange on all levels for information interchange between tools.

Rhapsody has an AUTOSAR profile that allows the import and export of ARXML files. When you want to use Rhapsody for Architecture you can then export your Rhapsody model as ARXML to do further work in other tools. The other way around is also possible, you can draw your architecture in a Vector or Elektrobit tool, export ARXML, import that in Rhapsody and then create RIMBOs to add behavioral elements.

Sounds complicated and… unfortunately…. it is. We at Willert have designed an “AUTOSAR light” solution that allows the use of Rhapsody on a much simpler level. We import ARXML but convert all items to standard UML items. You can add behavior in a normal Rhapsody way, generate code and… it works. in the current version you have to do some stuff by hand but we are working on automating that as well.

So….back to Fjällbacka… a very nice town, we can recommend a visit!

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Newer posts »

© 2026 Rhapsody TechBlog

Theme by Anders NorenUp ↑