Tag: Code Generation (Page 4 of 4)

The more Objects you ‘C’…

June 19, 2017 / rhapsody207 / 1 Comment

A BLOG entry… on this holiday in (most of) Germany.

Many years ago i was asked to work on a project in Germany, in Düsseldorf to be precise. That is when I found out that Germans have lots of holidays, probably more than anywhere in the world, at least a lot more then in the Netherlands.
The number is varying depending in where in Germany you are. The southern states have the most, the Northern states the least. The southern states are also the economically best ones…

Coincidence? I think not.

Since I’m now at home where everybody works, i have enough time to write a BLOG entry. Today about a question that is keeping the embedded world busy since a long time:

Shall I use ‘C’ or ‘C++’?

The answer is not really simple (as expected…). There is a simple answer, it is: “It depends”. Does not help…

Depends on what? Well… on a couple of things:

How is your ‘C++’ knowledge? It is not recommended to use an important project for your first ‘C++’ experience…. Stay with ‘C’ if you are comfortable with it.
Is there a decent ‘C++’ compiler for your target environment? With decent I mean a real, full-fledged, used by many others ‘C++’ compiler. Not a ‘C++’ front-end, not a crippled C++ compiler.
Do you have a lot of legacy code available in ‘C’ or in ‘C++’. Then that should be the language of choice

In earlier days other arguments would have been: how much memory does your target have? Today this is no longer valid. We (Willert) have Rhapsody frameworks available for C and C++ for many targets. We can also compare between both languages and we have measured that in many case C++ is smaller and faster than C!

For the hard-core ‘C’ programmers: Rhapsody in ‘C’ is an excellent way to learn Object Orientation and eventually ‘C++’!

I learned to program ‘C’ in 1982 in school. I tried to learn ‘C++’ end of the 1990’s. Bought me a book (Unfortunately “The C++ Programming Language by Bjarne Stroustrup”, not exactly a learning book…..) After reading this I was not a single bit wiser about ‘C++’ . I found it very difficult to understand what Classes and Objects were. When I started using Rhapsody in ‘C’ I started to understand OO while the OO was expressed in ‘C’, which I could read and understand.

So a real answer cannot be given but the trend is towards ‘C++’. My Advice: If you can use ‘C++: do it, if you can’t, think twice about alternatives.

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Properties. Stairway to heaven, highway to hell….

June 8, 2017 / rhapsody207 / 3 Comments

Where to change?

One of the cool features of Rhapsody is the large number of properties that allow you to configure many things to your needs.

One of the scariest features is the large number of properties that allow you to really make a mess of your model….

The truth here is somewhere in the middle. Properties are definitely very cool but should be used with care.

Do not use Factory.prp or Factory<Lang>.prp to let Rhapsody use your properties. Not never…. Every installation uses its own Factory files and they can be changed so copying them from an old installation is not an option. It is called “Factory” for a reason.
If you really have to change something globally, please use the “Include” statement in the prp files so that your properties are stored independent of the Rhapsody installation.
Using changes in Site or Factory are not really the best way of doing stuff. You have to install the same files on _every_ workstation in your organization otherwise it is possible that you are confronted with unwanted behavior.
Properties belong in a profile so that you can load many settings in one go. You can store the profiles under the Rhapsody Share directory (Share\properties). When you create a txt file with the same base name as the property file you can add a description and the “New Project” Dialog will show your property file under “Settings”
Not all properties can be set in a profile, model level properties for instance cannot be set on profile level.

Limit Roundtrip errors

A default setting in Rhapsody that really does not make any sense is the Roundtrip settings. Default Rhapsody lets you change whatever you want and hides the results for you. I’ve had crying man on the phone that were desperate while Rhapsody generated code that they could not understand. The default is OK for Rhapsody Experts, they know what to expect but for newbies it is just wrong.

So change:
Browser::Settings::ShowSourceArtifacts to TRUE and
C_Roundtrip::General::RoundtripScheme to Basic

That will limit your changes to what you can change anyway (Function contents and other stuff that is between /*#[ …. */ and /*#]*/

Model Beautifier

Curves are nice but in different types of models. Not in UML models. For reasons beyond our understanding IBM has chosen curved as default. There are a lot of properties involved to cure that. This is done best in a profile. In Subject “StatechartDiagram” you can find all the properties you need.
StatechartDiagram::Transition::line_style set to rectilinear (or rounded_rectilinear)
I think you can handle the rest of the properties yourself. Another that is useful is:
StatechartDiagram::Requirement::RequirementNotation set to Box_style if you want.
ObjectModelGe::Requirement::ShowAnnotationContents can be set to “Specification” because that is what you want to see.
As you see, all model elements have properties in different diagram types, yes… you have to change them all. A bit of work but very rewarding!

User defined Types

When using your own types you will notice that the PreDefinedTypes packages stay there (and cannot be deleted). You can however hide them with:Browser::Settings::ShowPredefinedPackage to False.
Then you can either create a package with your own types, or use a package with external types and include <stdint.h> to use C99 (or define C++ stdint types)
Change: General::Model::CommonTypes and add your own type packages (Use fully qualified names when using subpackages!, multiple packages can be separated by ‘,’) to have only your own types when selecting the type for attributes or arguments etc. In General::Model::DefaultType you can set the default (“TypePkg::Type”).

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Marquardt – Rhapsody unlocks doors

April 2, 2017 / rhapsody207 / 1 Comment

Introduction

The software development division of the Marquardt company decided in 2012 to switch from structured programming using ANSI-C to a model driven development approach using UML including automatic code generation. The reason was to have a better position in the future to master the increasing complexity and requirements in the automotive supplier market easily.

THE PROJECT

The first project where MDD was used was the development of a wireless keyless-entry/keyless-go system for a well known German car manufacturer. The hardware platform was a 16 bit controller with 64 Kb ROM and 4 Kb RAM. The application to be developed had to cope with limitations as the very small footprint, the minimal processing power and still require very little resources at startup time.

These challenges provided the Marquardt Software Design team with at the trigger- after successful proof of concept – to do a future oriented switch and become an ‘Early Adopter’ in Model Driven Development (MDD).

AT THE START

The assumption that MDD could be of great use in software development was initially quite controversial in the software development team. Also the question if the keyless system would be a suitable candidate for a pilot project was doubted, especially due to its stringent resource requirements and the short time to develop. However, in the end it became clear that the
traditional methods of structured programming could no longer be used for such high requirements and time constraints in future projects. And although this keyless system project was not an ideal candidate as pilot project, given the short Time-to-Market that is common in the Automotive market, Marquardt decided not to wait with their switch to MDD. Its customers would benefit enormous of the innovative approach. The risks were carefully calculated and Willert Software Tools GmbH offered Training and Coaching during the entire product development process and helped in the Switch and the changed process.

DURING THE PROJECT

The project was carefully planned as pilot project to recognise the advantages of MDD during development. An investigation of tools to use was carried out, based on the requirements with respect to memory- and CPU resource usage and realtime behaviour, to determine how feasible the introduction of MDD would be with respect to memory usage, performance and real-time requirements.

The positive outcome of this investigation was convincing. The idea that restrictions due to software development in ANSI-C could be surpassed, was clearly valid. The development team of the pilot project defined the following goals:

The Tools: UML as modelling language, modelling in IBM Rhapsody in C extended with the Realtime eXecution Framework (RXF) by Willert Software Tools (see infobox) made it possible to meet the specific technical requirements and use code generation for the limited memory- and CPU resources.

Realistic project conditions: It should be possible to realise the project without extra time or manpower. The use of trainer and coach from Willert Software Tools helped to meet these conditions.
Focus Quality Management: The effects of the use of MDD should be measurable and reproducible. The first project phase included training and coaching which assured a successful start and use of the tools. Next, well-defined training and coaching during development were the base for reaching planned schedule in time and costs plus quality and support the motivation within development team. The success of the first development proved the approach and selected tools to be the right choice.
During the project the restrictions with respect to footprint and CPU resources formed the technical boundaries. The methods and know-how of modelling were extended within the development team which helped greatly. In close cooperation with the Willert trainers and coaches and multiple workshops, even in close to final project phases, further optimisation in model and RXF were realised. In this pilot project all requirements regarding memory- and CPU resource usage and realtime behaviour were met.
In parallel the testing was tuned: unit tests, software in the loop and software integration were adapted to the modelling process and even automated. This was an extra effect which was not accounted for at forehand.

THE GAIN

First and most of all: a successful project and satisfied customer. At a functional level the project had realised what probably also could have been realised in the originally used development methods. But using MDD the road into the future with increasing demanding requirements is now open. Moreover, the quality aspect of the software engineering shows improved ease of maintenance, modifications and robustness. Apart from the functional result of this

pilot project, Marquardt now is capable of meeting steep requirements and specifically in reacting flexible on changes in requirements desired by the customer during the project. In addition, the steps needed in changing the development process and tasks within the team were mastered successfully. These changes were supported by the Willert trainer and coach. This resulted in a highly motivated team and guaranteed progress even in difficult times.

Most importantly is that the new know-how within the team and the investments in the new tools offer Marquardt a highly efficient and motivated team, ready for the future. This switch used by Marquardt in this project was acknowledged as an improvement of the software development.

THE FUTURE

Future projects will use the investments of this pilot project being the software tools, not-productive man-hours and consultancy, needed to introduce the new technology.

Traceability and maintenance of existing applications is much easier at the model level. The development process and applications therefore have become more defined and predictable. This will in its turn have positive impact on quality and time plus costs.

For the team members of the development team the switch to MDD means increasing competence and knowledge of modern software engineering.

The successful pilot project confirmed positively the decision taken to start using a new development environment and helped the customer in its success-story. This project proved Marquardt being an innovative company having a competent software development team which can cope with the ever-increasing demands of the automotive industry, ready for the future.

Inlay Marquardt Project

ABOUT MARQUARDT

Marquardt is an independent international and successful family owned company and leading manufacturer of electro-mechanic and electronic switches and -systems. Marquardt products are widely used by multiple car manufacturers. Marquardt also manufactures devices used in houses or for industrial appliances and is worldwide market leader in these areas.
http://www.marquardt.com

ABOUT WILLERT SOFTWARE TOOLS

The Willert Software Tools company specialises since 1992 in tools for Software Engineering with respect to realtime embedded systems. Willert has set its goal to offer technologies to enable customers to successfully develop software and support them in adapting the required tools. For this, Willert offers methods and tools plus training and coaching based on thorough knowledge of realtime embedded systems. Its customers include the automotive industry, aerospace, medical devices, public transport manufacturers, telecommunications, energy and infrastructural environment. Willert Software Tools has helped with numerous product specification, -development and Quality Assurance, for example vehicle control devices, coffee machines, frequency inverters, satellites, hearing instruments, door controls, fire alarms, röntgen devices, positioning systems and robotics.