COMPONENT-BASED BASE-PLATFORM
RHAPSODY ON MICROCONTROLLERS
Claes Paulsson
cpn02004@student.mdh.se
Master Thesis in Computer Science, 20p D-level
Mälardalen University
CC-SYSTEMS AB
Västerås, Sweden
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 2 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Intentionally left blank.
2 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 3 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
ABSTRACT
CrossFire MX1 is the name of a programmable IO module and controller that have been
developed by CC-Systems and is intended for mobile applications in tough environments. The
module is intended for use in decentralized systems with installation close to the unit to be
handled. Unlike other controllers that need to be installed in a protected environment the
CrossFire MX1 can be mounted directly on the controlled unit, for example on the harvester
head to some of John Deere Forestry’s harvesters.
The programming of this module is usually handled by PLC-tools or with compilers like
Tasking and Keil. In the future CC-systems wants it to be easier to program their CrossFire
module and have therefore begun to investigate if model based development tools can be used
for this purpose. By switching from the traditional way of programming to the new model
based way the company’s hope is to gain several benefits over their competitors. Benefits like
shorter development time, less complexity, code that is easier to maintain/upgrade etc.
I this thesis, drivers for the CrossFire MX1 module have been integrated in the model based
development tool Rhapsody. A demonstrator and applications for controlling and simulating
the behaviour of the CrossFire module have also been developed. Testing equipment and
cables have been constructed according to the CrossFire MX1 manual.
Different solutions of how the drivers could be integrated were made and compared regarding
usability and functionality. The demonstrator used the integrated drivers and was put into
operation on the CrossFire MX1 module where it communicated with the testing equipment as
well as the control application.
3 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 4 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
SAMMANFATTNING
CrossFire MX1 är namnet på en programmerbar IO modul och kontroller som tagits fram av
CC-Systems för att användas för mobila tillämpningar i tuffa miljöer. Modulen är avsedd att
användas i decentraliserade system nära den enhet den hanterar. Till skillnad från andra enheter
som måste installeras i en skyddad miljö kan CrossFire MX1 monteras direkt på den styrda
enheten, till exempel på skördaraggregatet till några av John Deere Forestrys skogsmaskiner.
Tidigare så har programmeringen av denna enhet skett med hjälp av PLC verktyg eller med
kompilatorer som Tasking och Keil. CC-Systems vill i framtiden att det ska bli enklare att
programmera deras CrossFire modul och har därför börjat undersöka om det går att använda
sig av modellbaserade verktyg för detta ändamål. I och med en övergång från det mer
traditionella programmeringssättet till den nyare modellbaserade varianten hoppas företaget
vinna flera konkurrensfördelar. Fördelar som förkortad utvecklingstid, lägre komplexitet, kod
som är lättare and underhålla/uppgradera osv.
I detta examensarbete har drivrutiner för CrossFire MX1 integrerats i det modellbaserade
verktyget Rhapsody. En demonstrator samt applikationer för att styra och simulera beteendet
av CrossFire modulen har också utvecklats. Test utrustning och kablage har konstruerats i
enlighet med manualen för CrossFire MX1.
Olika lösningsförslag på hur drivrutinerna kunde integreras gjordes och jämfördes med
avseende på användarvänlighet och funktionalitet. Demonstratorn använde sig av de
integrerade drivrutinerna och driftsattes på CrossFire-enheten där den kommunicerade med
testutrustningen liksom styrprogrammet.
4 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 5 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
CONTENTS
1
Introduction ...................................................................................................................... 12
1.1
Background ................................................................................................................ 12
1.2
Goal and purpose ....................................................................................................... 13
1.3
Scope/Delimitations ................................................................................................... 13
1.4
Disposition ................................................................................................................. 14
2
CC-Systems AB ................................................................................................................ 15
3
Requirements of this thesis ............................................................................................. 16
3.1
Strong requirements ................................................................................................... 16
3.2
Weak requirements..................................................................................................... 16
4
Problem formulation ....................................................................................................... 17
5
Analysis of problem ......................................................................................................... 18
6
Procedure .......................................................................................................................... 19
7
Related work and technologies ....................................................................................... 21
7.1
Related work .............................................................................................................. 21
7.1.1
Utvärdering och testning av Rhapsody .............................................................. 21
7.1.2
Driftsättning av ett distribuerat styrsystem på hårdvara .................................... 21
7.1.3
Utredning av styrsystem på modern brandbil .................................................... 22
7.2
UML & Code generation tools .................................................................................. 23
7.2.1
Introduction to UML .......................................................................................... 24
7.3
Rhapsody .................................................................................................................... 32
7.3.1
Example ............................................................................................................. 33
7.3.2
Interrupt Driven Framework (IDF) .................................................................... 34
7.4
CAN – Controller Area Network................................................................................ 35
7.4.1
Introduction ........................................................................................................ 35
7.4.2
History................................................................................................................ 35
7.4.3
How the CAN protocol works ........................................................................... 35
7.4.4
CANopen ........................................................................................................... 37
7.5
Tasking ....................................................................................................................... 38
7.6
CCSimTech ................................................................................................................ 39
7.6.1
Introduction to CCSimTech ............................................................................... 39
7.6.2
IOTool ................................................................................................................ 41
7.6.3
BusTool .............................................................................................................. 42
5 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 6 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
8
CrossFire MX1 ................................................................................................................. 43
9
Drivers for CrossFire MX1 ............................................................................................. 46
9.1
Description of IO and CAN driver interface.............................................................. 48
9.1.1
IO ....................................................................................................................... 48
9.1.2
CAN ................................................................................................................... 50
10
Rhapsody on Microcontrollers ................................................................................... 54
10.1
Description of the study ............................................................................................. 54
10.2
Problems .................................................................................................................... 54
10.3 Analysis ...................................................................................................................... 54
10.3.1 The Drivers ........................................................................................................ 54
10.3.2 Interface & Architecture .................................................................................... 55
10.4 Solution ...................................................................................................................... 55
10.4.1 Proposal 1........................................................................................................... 55
10.4.2 Proposal 2........................................................................................................... 57
10.4.3 Integration of proposal 1 .................................................................................... 58
10.4.4 Integration of proposal 2 .................................................................................... 59
10.4.5 Problems ............................................................................................................ 60
10.4.6 Final solution ..................................................................................................... 61
10.4.7 Settings for compilation and linking .................................................................. 62
10.5
11
Results ........................................................................................................................ 63
The demonstrator......................................................................................................... 64
11.1
The creation of the demo project ............................................................................... 64
11.2
The Control Panel ...................................................................................................... 68
11.3
The Testing equipment ............................................................................................... 68
11.4
Requirements and functions verified by the demonstrator ........................................ 69
12
Model based development vs Traditional .................................................................. 70
12.1
Background ................................................................................................................ 70
12.2
Comparison Rhapsody vs traditional development methodology .............................. 70
12.3
Rhapsody vs Tasking/Visual Studio ........................................................................... 73
13
Flash loading of CrossFire MX1 ................................................................................. 76
13.1
14
Settings in Rhapsody’s property file .......................................................................... 80
Discussion and Conclusion .......................................................................................... 82
14.1
General about MBSE ................................................................................................. 82
6 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 7 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
14.2
The Thesis work ......................................................................................................... 82
14.3
Conclusion ................................................................................................................. 82
15
Glossary ........................................................................................................................ 83
16
References ..................................................................................................................... 85
7 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 8 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
LIST OF FIGURES
Figure 6.1 - Working procedure................................................................................................. 20
Figure 7.1 – Class Diagram ....................................................................................................... 24
Figure 7.2 – Component Diagram ............................................................................................. 25
Figure 7.3 – Composite Structure Diagram ............................................................................... 25
Figure 7.4 – Deployment Diagram ............................................................................................ 26
Figure 7.5 – Object Diagram ..................................................................................................... 27
Figure 7.6 – Package Diagram ................................................................................................... 27
Figure 7.7 – Activity Diagram ................................................................................................... 28
Figure 7.8 – State Machine Diagram ......................................................................................... 28
Figure 7.9 – User Case Diagram ................................................................................................ 29
Figure 7.10 – Communication Diagram .................................................................................... 29
Figure 7.11 – Interaction Overview Diagram ............................................................................ 30
Figure 7.12 – Sequence Diagram ............................................................................................... 31
Figure 7.13 – Time Diagram ...................................................................................................... 31
Figure 7.14 - Rhapsody, example of development environment. .............................................. 33
Figure 7.15 - IDF Package ......................................................................................................... 34
Figure 7.16 – Beginning of CAN frame. ................................................................................... 36
Figure 7.17 – End of CAN frame............................................................................................... 36
Figure 7.18 - Tasking EDE ........................................................................................................ 38
Figure 7.19 - CCSimTech tools ................................................................................................. 39
Figure 7.20 - IoTool ................................................................................................................... 41
Figure 7.21 - BusTool ................................................................................................................ 42
Figure 8.1 - CrossFire MX1 ....................................................................................................... 43
Figure 8.2 - CrossFire Nodes ..................................................................................................... 43
Figure 9.1 – The drivers ............................................................................................................. 46
Figure 10.1 – Drivers packages, proposal 1 ............................................................................... 56
Figure 10.2 – Drivers package, proposal 2 ................................................................................ 57
Figure 10.3 - CAN package, proposal 1 .................................................................................... 58
Figure 10.4 - IO package, proposal 1 ......................................................................................... 58
Figure 10.5 - Proposal 2 ............................................................................................................. 59
Figure 10.6 – Final solution ....................................................................................................... 61
Figure 11.1 - CrossFire MX1 demonstrator ............................................................................... 65
Figure 11.2 – State chart diagram of class IO class ................................................................... 65
Figure 11.3 – State chart diagram of CAN class ....................................................................... 66
Figure 11.4 – The Demonstrator simulated ............................................................................... 67
Figure 11.5 - CrossFire MX1 Control Panel .............................................................................. 68
Figure 11.6 – Simulated test box ............................................................................................... 69
Figure 12.1 – Benefits of model based software development .................................................. 72
Figure 13.1 – Erasing by using FLASHit .................................................................................. 76
Figure 13.2 – Flash loading with Tasking ................................................................................. 77
Figure 13.3 – Configuration file for Flash loading with Tasking 8.5 ........................................ 78
8 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 9 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 13.4 - CrossView ............................................................................................................ 79
Figure 13.5 - CrossView, Download Application ..................................................................... 79
Figure 13.6 – Generation of Configuration File. ....................................................................... 80
Figure 13.7 – Code for generation of Config, Command and Bat-file ...................................... 81
9 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 10 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
LIST OF TABLES
Table 8.1 – Data Sheet CrossFire MX1b ................................................................................... 45
Table 9.1 – Drivers for IO.......................................................................................................... 46
Table 9.2 – Drivers for CAN ..................................................................................................... 47
Table 12.1 – Specifications of Node A and Node B .................................................................. 71
Table 12.2 – Functional similarities........................................................................................... 71
Table 12.3 - Results ................................................................................................................... 71
10 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 11 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
PREFACE
This is my thesis work for a Master Degree in Computer Science. The work is performed for
CC-Systems AB at CC-systems office in Västerås from November 2006 to April 2007.
I would like to take the opportunity to thank my supervisors Johan Fredriksson and Jonas Ehlin
for the help and support they been giving during this thesis work. I would also like to thank
other members of the staff of CC-Systems in Västerås, in front of all Anders Öberg whose help
have been invaluable during this thesis work. I would also like to thank Adam Åström, Fredrik
Löwenhielm and Lena Winroth for then help they contributed with. Also a great thank to Dag
Erlandsson at the company Nohau Electronics AB for the help provided.
Examiner at Mälardalen University
Rickard Land
rickard.land@mdh.se
Supervisor at Mälardalen University
Johan Fredriksson
Johan.fredriksson@mdh.se
Supervisor at CC-Systems
Jonas Ehlin
Jonas.ehlin@cc-systems.se
11 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 12 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
1 INTRODUCTION
1.1 Background
CC Systems AB is a company that develops and delivers advanced control systems for vehicles
and mobile equipments in though environments [7]. Tough environments means environments
where the products are exposed to strains like wet, dirt, shocks, vibrations and even EMC
(Electromagnetic Compatibility) which means that it is resistant to electromagnetic
disturbances and doesn’t produce such disturbances. Some examples of vehicles that are
operating in tough environments and are in need of CC-Systems solutions are construction
equipments, forestry harvesters and military vehicles. CC-Systems are cooperating with several
large customers like John Deere Forestry, BAE Systems Hägglunds, Volvo CE, Atlas Copco,
Bombardier, ESAB and more. The company is working with development of electronics and
software, production and deliveries of system solutions and also products for vehicle and
machine control.
In this thesis I’ve worked with a programmable IO module and controller called CrossFire
MX1. This general and flexible IO module and controller is adapted for tough environments
and is part of a general solution were it can be connected with several of the company’s
products like CC Pilot XS/XL. If CC-Systems shall be able to offer their customers a simple
and efficient development environment for application development of their microcontrollers,
drivers and other software have been implemented into a Rhapsody project. Rhapsody is a
component based software engineering tool where a developer with help of graphical
components and UML is able to develop his application. Rhapsody is a code generating tool
which means that the design made in Rhapsody is automatically translated into C++ or C, Ada
and Java if that’s to prefer.
The background of this thesis is that CC-Systems want to offer their customers a simple and
efficient way to program the products they’re selling, this to improve the usability and to
increase the competitiveness.
12 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 13 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
1.2 Goal and purpose
The goal with this thesis has been to create a Rhapsody project and implement the drivers of
the CrossFire MX1. The drivers’ packages are then supposed to easily be implemented into
another already existing Rhapsody project. The user in this case would be the programmer that
is programming the CrossFire module and is in need of the drivers.
The purpose of this thesis is to investigate how the architecture and the interface should be
designed to facilitate the work for the software developer. The drivers of the Crossfire MX1
will be integrated into the Rhapsody environment and put into operation. The purpose is further
that the application developer should be able to use the completed Rhapsody project as a
foundation when he or she later is supposed to use Rhapsody to develop systems where the
CrossFire MX1 is a part.
The purpose is also to create a demo application in Rhapsody that uses the driver project to
show that everything works correctly.
1.3 Scope/Delimitations
The thesis work will comprise a starting period of about five weeks intended for learning,
background about CC systems and a self-course in Rhapsody. During this five-week period the
purpose is to get to know about the drivers for the CrossFire MX1 and study how an existing
project uses the CrossFire MX1, just to get some hints of possible solutions (unfortunately
such a project was not available). Continuously during the work important information and
headlines were noted. This information would later form the basis of this report.
After completed the feasibility study a presentation for the company will be held where the
results will be shown and where I present how I’m supposed to continue the work. The
remaining part of the work is calculated to approximately 15 weeks and during this period I
will work with researching, integrate the drivers into Rhapsody and verify the result both in a
simulated environment and against target. I will investigate what the architecture and interface
will look like so that the CrossFire MX1 will be connected with Rhapsody in the best way. In
parallel to this work I will also developed two graphical applications with help of Visual
Studio. With these applications the testing of the CrossFire module will become much easier.
The writing of this report will also take a big part of this period.
The purpose of this thesis work is not to create a ready-to-use product which can be sold to a
customer. Instead, after the completion of this thesis CC-Systems should be able to study the
results and make a decision if it is worth to continue work with Rhapsody and how it can be
achieved.
13 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 14 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
To be able to perform a test against the target (CrossFire MX1 module) I had to construct a
testbox from which one can send and receive signals to/from the ports of the CrossFire MX1.
The goal was to get the same results in both the simulated environment and the real test. There
existed several different drivers for the CrossFire MX1 but in this thesis work I was never
supposed to integrate all of them, just the most important needed to perform tests, which are
the drivers for IO and CAN.
1.4 Disposition
This thesis report has been constructed as a combination of the thesis template of the
University and the thesis template of CC-systems. In the beginning of this report the problem
formulation is discussed and a more deep analysis of the problems is presented. The report
continues by presenting related works and related technologies that are necessary for the reader
to have some basic knowledge about. If the reader of this report already has some basic
knowledge about some of the presented areas the reader can skip those areas. To fully
understand this report and the problems discussed, basic experiences of working with
Rhapsody are required.
The main part of this report has been divided into several sub-headlines which describe the
work, decisions made and the result. The report is also describing the IO-Controller (CrossFire
MX1) I have used and the demonstrator which purpose is to show that correct results have
been achieved. The report does also contain a chapter where a comparison between model
based software development with Rhapsody and traditional development with Visual Studio
and Tasking is made.
Finally the report ends with a discussion/conclusion part where comments about this thesis are
given.
14 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 15 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
2 CC-SYSTEMS AB
CC-Systems AB (Cross Country AB) was founded in 1991 when it separated from ÖSA
(Östbergs Fabriks AB) and has since the start had a strong growth combined with positive
results. Since 1999 the turnover has more then four-doubled (from 43MSEK to 175 MSEK)
and the number of employees has more then tripled [4].
CC Systems AB is a company that develops and delivers advanced information and control
system solutions for vehicles and mobile equipments in tough environments. With tough
environments means environments where the products are exposed to strains like wet, dirt,
shocks, vibrations and also EMC. Some examples of vehicles working in though environments
and are in need of CC Systems solutions are construction equipments, forestry harvesters,
mining machines and military vehicles. CC-systems are cooperating with several large
customers like ESAB, John Deere Forestry, Scanjack, BAE Systems Hägglunds, Volvo CE,
Atlas Copco, Bombardier and more. The company works with development of electronics and
software, production and deliveries of system solutions and products for vehicle and machine
control.
CC Systems has since the start 1991 introduced several different products like displays, onboard computer, IO modules, controllers, application modules and communication modules.
Today the company has more than 180 employees divided in offices in Alfta, Uppsala,
Västerås, Örnsköldsvik and Tammerfors and plans to possibly open an office in Malaysia does
also exist.
15 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 16 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
3 REQUIREMENTS OF THIS THESIS
For this thesis work I have made up a list of requirements that I want to fulfil. The
requirements are divided into strong requirements and weak requirements. Strong requirements
are more important than the weak ones.
3.1 Strong requirements
Req.
Id
Rs1
Rs2
Rs3
Rs4
Rs5
Rs6
Rs7
Requirement description
Integrate the drivers of the CrossFire MX1in a Rhapsody project.
Develop different propositions of possible solutions and make a comparison between
them.
Develop a demonstrator in Rhapsody that uses the integrated drivers.
Develop a control panel from witch a user can communicate with the demonstrator.
Construct a test box for sharp testing against target.
Develop an application for simulation of the test box.
Perform tests in both a simulated environment and against target, the results from the
tests must match.
3.2 Weak requirements
Req.
Id
Rw1
Rw2
Rw3
Rw4
Requirement description
The demonstrator and the control panel shall communicate through a CAN bus.
The demonstrator should allow the user to change all the settings supported by the IO
drivers.
The flash loading procedure should be automatically called from Rhapsody.
The final solution of the Rhapsody project should be both functional and user
friendly.
16 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 17 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
4 PROBLEM FORMULATION
When software developers today want to program the CrossFire MX1 they must write C/C++
code and compile it for the Infineon C167CR CPU which is inside the CrossFire MX1.
Alternatively they can use PLC (Programmable Logic Controller) programming. Programming
in this way is considered to be programming at a fairly low level (the idea is that an ordinary
customers should be able to program the CrossFire MX1 and not only an educated
programmer) and at CC Systems this is a problem. Experiences from programming in this way
shows that it often takes long time, the programmer must many times focus on things that do
not have to do with the main function, for example the drivers. This does often cause hidden
errors which take even more time to localize and correct. CC Systems want that the customers
in the future should have the possibility to use tools that allow programming at a higher level.
Programming at a higher level has many advantages:
1. The programmer may focus more on the main function and less on implementation.
2. The programmer do not need to deal with drivers, instead he or she can use packages
which are already well tested.
3. The code is being generated which means that less bugs occurs.
4. Thanks to the decreased complexity the company saves time and money.
5. It gets easier to debug and perform changes/updates.
To make it easier to program the CrossFire the idea is that the developer should program using
UML instead of C/C++ and therefore CC-Systems want to investigate if they can use I-Logix
Rhapsody to program the CrossFire MX1.
17 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 18 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
5 ANALYSIS OF PROBLEM
During the thesis work I have encountered both minor and major problems which needed to be
fixed and in this chapter I present the analysis of the problems that i formulated in the
beginning of this work. The analysis aims to identify and divide the problems into smaller
parts.
To succeed with this thesis the following problems must be solved:










Learn how to use Rhapsody, understand how it works and figure out what’s possible to
do and what’s not.
Get to know the drivers, identify the necessary files and understand how to use them.
Investigate what the architecture and interface should look like and how to best
combine functionality with usability. How does the customer want to have it?
Integrate the drivers in a Rhapsody project so that they can be imported and used by
other Rhapsody projects.
Understand how CC-systems simulation technology CCSimTech works and how to use
it for simulation and testing against target.
Get to know the CrossFire MX1 module, what is possible to do and how can I test the
unit?
How should the demonstrator be designed, what should be possible do and what should
it verify?
How can the simulation be achieved? What needs to be simulated?
How can the test against the target be achieved, what should I test against? Do I have to
create my own testing equipment or does such equipment already exist?
How does the flash loading work and how can I make this happen from Rhapsody?
Except these problems other unexpected problems did also occur. For example, my CrossFire
MX1 example was designed wrong and the user manual was not update according to the latest
B-version of the CrossFire MX1. The CrossFire module was wrong constructed because it had
been assembled as a combination of the elder A-model’s upper circuit board and the new Bmodel’s lower circuit board. All cables required for power, flash loading, CAN and IO had to
be constructed manually.
To be able to solve these problems I’ve got lot of valuable help from people within CCSystems.
18 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 19 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
6 PROCEDURE
In the beginning I and my supervisor had an introduction meeting where we went through the
information about the thesis that I received. My supervisor explained in more detail the
purpose of the thesis and the different parts involved. By this time it was not crystal clear how
the work should be done but during the meeting important notes were made and a simple time
schedule was created. It was also decided that a project description should be written and sent
to my supervisor for review. When both of us were satisfied with the formulation of the project
description it was sent to the school.
To begin, a five-week period was reserved intended for learning and introductive research.
There were lot of information to read, I had to repeat UML and learn how to use Rhapsody.
The first two weeks was spent doing self-courses in Rhapsody and reading information about
the application on the internet (most information came from the manufacturer’s homepage).
After that I had two more meetings with my supervisor and employees at CC-Systems where
we discussed more about the thesis work and what contacts I could question regarding
information about the CrossFire MX1 module and its drivers. I did also get access to CCSystems database where I could download information about the module and get the drivers.
The remaining three weeks of the introduction period was spent reading information about the
CrossFire MX1 and the drivers.
There were also a lot of other related technologies that I needed to study, for example CAN
and CC-Systems simulation technology CCSimTech which I will explain further in this report.
I parallel with the research different parts of this report were written.
One of the ideas from the first meeting was to investigate an already existing solution that uses
Rhapsody and CrossFire MX1; however such a project did not exist. Instead I got access to
two other Rhapsody projects that I could study to get more knowledge about what my solution
should look like. A tip for those how work in a project is to write daily notes about the work,
problems encountered and solutions. By doing this it is much easier to go back an see what one
have done, how different problems were solved and this is a big help when writing a report.
The main part of this thesis work was spent integrating the drivers in Rhapsody and
investigating how the interface and architecture in the best way should be designed. To be able
to verify that the integration had succeeded and that my solution was user friendly and
functional some other applications needed to be developed as well. One application intended
for demonstration, and two other applications intended for simulation of the testing equipment
and controlling of the demonstrator. The writing of this report did also take many weeks during
this time period.
19 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 20 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
CC Systems have prior knowledge about thesis works and have earlier applied a certain
working procedure. This working procedure looks like Figure 6.1.
Figure 6.1 - Working procedure
The working procedure starts with the industrial problem; analyse and divide the problem into
smaller pieces. After the problems have been identified and analysed the working procedure
moves on with the research part where the thesis worker should do some research that
hopefully will lead to the first prototype. When a prototype is ready it needs to be tested and
verified to make sure that the solution is sustainable otherwise it needs to be redesigned. The
last part of the working procedure is to validate the final solution; this step is not always a
necessary part of a thesis work. In this thesis it’s not a necessary part.
20 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 21 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7 RELATED WORK AND TECHNOLOGIES
7.1 Related work
There are lots of thesis works already completed by other students at Mälardalen University
(and other Universities) which more or less reminds about this thesis work. In this chapter
three different related thesis works are presented. These reports may give the reader a better
understanding of the different technologies and problems regarding this kind of thesis work.
Unfortunately the reports are only available in Swedish.
7.1.1 Utvärdering och testning av Rhapsody
(2001, 10p C-level, Mälardalen University, Jorge Råström) [1]
This thesis work is a 10 point C level thesis performed by Jorge Råström, student at
Mälardalen University and for the company Tieto Enator ArosTech. In the report an
investigation about whether Rhapsody is suitable for software development of built-in systems
and real time systems is made. In the report a careful review of how UML and Rhapsody
works is given. The report continues with a problem description, what demands should be
made on a tool intended for modelling of real-time applications. After that a description of the
modelled test system is made and the results are presented.
The conclusion the student can make from this thesis work is that good knowledge about
UML, real time programming and Rhapsody is required if one wants to fully use Rhapsody for
software engineering. The author of this work gives a big plus fore the tree-view in Rhapsody
which gives a great overview of the project and a big plus for the animation function which is a
great tool for debugging. Users of Rhapsody are also recommended to have a powerful
computer to make the application run smooth.
7.1.2 Driftsättning av ett distribuerat styrsystem på hårdvara
(2001, 10p C-level, Mälardalen University, Helene Söderbergh) [2]
This 10-points C-level thesis work is performed by Helena Söderbergh for CC Systems in
Uppsala and in cooperation with Mälardalen University at Västerås. The purpose of this work
was to put a distributed control system into operation on CC Systems’ IO module CrossFire
MX1.
The report starts with a brief introduction part and a problem description part. After that the
report moves on with some relevant theories where the reader gets a basic introduction to
System 2000. Chapter 6 in the report is about the main work of the thesis and is followed by
21 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 22 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
result part where the results from the measurements are presented. Problems occurred during
the work is also presented in this part.
The conclusion made from this work is that the main goal of putting the System 2000 into
operation on CrossFire MX1 only was fulfilled to 75%. Problems with availability of CrossFire
MX1 units and lack of time were some of the reasons. Also problems with flash loading of the
unit did also occur.
This thesis work does have many similarities with the thesis work I’ve made, for example; the
student shall do a research and put a system into operation on the CrossFire MX1 module. A
demonstrator will be developed to verify correct result. Tests shall be made both in simulated
environment and against target. The testing equipment will be constructed by the student
him/herself. The result from the simulation and the real test shall match. The student must
write a report where background, problem description, performance, results and conclusions
are standard parts.
7.1.3 Utredning av styrsystem på modern brandbil
(2004, 10p C-level, Mälardalen University, Malin Jansson & Per Lundkvist) [3]
This work is a 10-points C-level thesis performed by students at Mälardalen University. The
students are Malin Johansson and Per Lundkvist and their thesis is about investigating how
control systems for modern fire fighting cars should be designed. The name of the company for
which this thesis is made is Sala Brand and the company is located in Sala. Sala Brand
produces fire fighting cars and rescue equipments for emergency services within municipality
and industry.
In this report the reader gets a good insight of how PLC programming works. PLC
programming is one of the elder tools used by CC-Systems when programming their IO
modules like CrossFire MX1. The report does also contain a detailed description of CAN and
different CAN based protocols like CANopen and CANKingdom. The reader gets a careful
insight into how systems with many nodes work and cooperate through a CAN network to
form a complete solution.
In the report a comparison between two fire fighting cars is made, one elder and one modern.
Results from the comparison and interview from employees at Arlanda-Brome rescue service
are presented. In the report demands for future equipments made by Sala Brand are listed and
six potential suppliers are questioned to examine which one of them that best fulfils the
demands.
The result from the investigation shows two companies that are most suited and those
companies are STW Systems and CC-Systems because both companies have robust products
which fulfil the demands and the companies proved to have big interest in assisting at start-up.
22 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 23 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
RELATED TECHNOLOGIES
7.2 UML & Code generation tools
For companies working with development of software it has during
the recent years become more and more popular to use code
generating applications as alternative to ordinary compilers. A code
generating tool is an application where the developer can use
graphical objects and diagrams to describe the functionality of the
software being developed. The benefits of using a code generation
tool are many; the development of the software gets less complex and takes less time and the
number of buds decreases. It’s easier to create a reliable and stable architecture when all the
parts and connections are visualised. Thanks to the great visibility a code generating tool
provides the developer can focus more on functionality and less on implementation.
When designing an application by using a code generating tool one specifies the objects and
components needed and how they are connected. By using diagrams the developer can then
describe how each component should behave and how the components should cooperate. When
the design is ready the developer can let the tool translate the design into code, quick and free
of bugs. How well the code is generated and how easily it can be modified depends on the
generation tool but one thing is for sure and that is that in the future theses tools will be better
in discovering errors in the design and generating optimized code. Today already good code
generating tools do exist, for example Telelogic Rhapsody where one can generate code for
several different compilers and languages.
For software design there is one language today that dominates the market and this language is
called UML – Unified Modelling Language. UML is an ADL language (Architecture
Description Language) and was created by Grady Booch, James Rumbaugh and Ivar Jacobson
in the middle of the 90s [17]. These people hade prior experiences of own design methods and
decided to work together to create a common language with all the benefits of their previous
languages. 1997 UML 1.0 was OMG – standardized, OMG is an acronym for Object
Management Group which is a standardization organisation funded in 1989 by several big
companies like IBM, HP, Sun and Apple. Microsoft’s announcement of UML and IBM’s
acquisition of the company Rational became the breakthrough for UML which became a musthave for most software companies.
UML is entirely free for companies to use and that is probably one of the reasons for why the
standard has become accepted worldwide. Since the introduction 1997 several minor versions
of the UML-standards have be introduced but quite recently (2003) version 2.0 of the UML
specification was introduced. With version 2.0 the UML specification has underwent a big
revision and this time in cooperation with over 50 different companies world wide. In the new
version you can find all tools you need for programming in diagrams instead of code. A
23 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 24 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
drawback with UML is the lack of semantics, i.e. there is no support for describing how the
application is supposed to work only how it is constructed.
On the market today there are several development applications that supports UML, for
example Rational rose, Telelogic Tau, Microsoft Visio and the tool I’ve been using Telelogic
Rhapsody.
7.2.1 Introduction to UML
7.2.1.1 Structural Modelling Diagrams
The structure diagrams aims to show how a system is built-up by classes, components, objects,
packages etc and how they are connected.
7.2.1.1.1 Class Diagram
The class diagram (Figure 7.1) is used to show all classes in the architecture, what attributes
and methods they got and how they are related. A class is represented as box with two filed
inside, one filed for the attributes and another for the methods. Between the classes there are
lines with different kinds of symbols that specify the relations between the classes. A relation
between two classes can be one of following; Association, Aggregation, Composition and
Generalisation.
Figure 7.1 – Class Diagram
24 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 25 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.2.1.1.2 Component Diagram
The Component Diagram (Figure 7.2) describes how a system physically is built-up with
components. A component can for example be files, modules, packages, executable files,
headers and linking libraries.
Figure 7.2 – Component Diagram
7.2.1.1.3 Composite Structure Diagram
The Composite Structure Diagram (Figure 7.3) describes how a class internally is designed.
This diagram contains parts like Ports, Parts and Interfaces.
Figure 7.3 – Composite Structure Diagram
25 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 26 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.2.1.1.4 Deployment Diagram
A deployment diagram (Figure 7.4) shows the hardware (nodes) in a system, what components
are placed in what hardware and how are they connected.
Figure 7.4 – Deployment Diagram
7.2.1.1.5 Object Diagram
Object Diagrams (Figure 7.5) are used to show the entire system or parts of it at a certain point
of time. They are similar to the class diagrams but are more suitable for describing how the
relationship between different classes evolves during the time.
26 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 27 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 7.5 – Object Diagram
7.2.1.1.6 Package Diagram
A package diagram (Figure 7.6) show how a system is separated into logical units or packages.
A package is usually a folder containing files.
Figure 7.6 – Package Diagram
27 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 28 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.2.1.2 Behavioural Modelling Diagrams
The behavioural modelling diagrams aims to show the behaviour of the system and how
different parts of the system interact over time.
7.2.1.2.1 Activity Diagram
The activity diagram (Figure 7.7) shows the execution flow between different components
from start to end. Here the developer has an overview of the different paths between the
components in the execution.
Figure 7.7 – Activity Diagram
7.2.1.2.2 State Machine Diagram
A state machine diagram (Figure 7.8) is the diagram that describes the behaviour of a singel
object. The diagram shows the different states an object can have during its lifecycle as wells
as the events that makes the object changing state.
Figure 7.8 – State Machine Diagram
28 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 29 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.2.1.3 User Case Diagram
The user case diagram (Figure 7.9) identifies the users of the system and specifies what the
users can do with it. The user case diagram is close connected to the requirements specification
of the system.
Figure 7.9 – User Case Diagram
7.2.1.3.1 Communication Diagram
The communication diagram (Figure 7.10) shows how different objects communicating with
each other. This diagram shows a combination of the Class, Sequence and User Case diagrams
and describes the static, structural and dynamic behaviour of the system.
Figure 7.10 – Communication Diagram
29 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 30 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.2.1.3.2 Interaction Overview Diagram (UML 2.0)
The interaction overview diagram (Figure 7.11) is a variation of the activity diagram and
consist of nodes where every node can represent an optional interaction diagram. With this
diagram the developer gets an overview of how the different interaction diagrams cooperate.
Figure 7.11 – Interaction Overview Diagram
7.2.1.3.3 Sequence Diagram
The sequence diagram (Figure 7.12) shows objects like classes in a row with a vertical time
line. The sequence diagram shows how different classes use each others methods to perform a
specific user case.
30 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 31 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 7.12 – Sequence Diagram
7.2.1.3.4 Time Diagram (UML 2.0)
The time diagram (Figure 7.13) shows how a state or value changes over time.
Figure 7.13 – Time Diagram
31 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 32 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.3 Rhapsody
Telelogic Rhapsody is a UML and code generating tool that lets the developer use diagrams
and graphical models to program his/her application. There are series of different programs out
on the market today that uses UML for software engineering, but not all of them provide code
generation. One example of a UML application that only provides design of systems is
Microsoft Visio. Applications that also provide code generation are IBM’s Rational Rose,
Telelogic Tau and Telelogic Rhapsody.
In Rhapsody you are working in a modelling environment and using diagrams and graphical
components to specify a certain function (see Figure 7.14). The benefits are many; essentially
shorter development time and code of higher quality are the foremost. In Rhapsody you can do
everything from requirement specification, design, implementation and testing of the complete
product. The tool combines the power of UML (Unified Modelling Language) and SysML
(System Modellling Language) and supports the latest versions of theses specifications.
In Rhapsody version 6.1 you can create applications in the following languages; C, C++, Ada
and Java for 8 up to 64 bits. By using different frameworks the developer can program
applications for a number of different operating systems, real time operating systems or OS at
all.
In Rhapsody you work with projects like many other development environments. What are
special about Rhapsody are the concepts Components, Configurations and Packages which are
described later in this chapter. A Rhapsody project must consist of at least one component but
can contain several. Each component needs at least one configuration and one package but can
have several different configurations and contain many packages. When a project is being built
(code generation) only one component and one configuration can be active. Components can
depend on each other and therefore the order of which they are being generated is important.
In a Rhapsody project it is possible to import ready components, configurations and packages,
even code written in other applications can be imported by using the tool reverse engineering.
If using C++ as in my case each out generated package will result in an h and cpp file. If the
packages belongs to other packages they will be out generated in a folder structure that is
similar to the structure of the packages in the project.
Except on project level the component level is the highest and all settings made there will
automatically be applied to all the packages and configurations belonging to the component.
Local setting made on package level will yet always be applied before settings made on
component level. For each component the developer can select Scope. Scope is a list where the
developer specifies which packages that should belong to the component.
All code written is placed in packages. A package may contain classes, functions, types,
variables and dependencies to other packages.
32 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 33 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 7.14 - Rhapsody, example of development environment.
7.3.1 Example
On the picture above (Figure 7.14) an example of a Rhapsody project is shown. In this example
the project is a simulation of the functionality of a dishwasher. In the left field a tree-view of
the project is shown. In the top is the folder Components which contains the component Test.
The Test component contains two configurations with the names Debug and Sim. The
configurations contain settings that have to do with the compiling and linking of the
component. A few steps down in the tree-view is the folder Package which contain all
packages. In this example only one package is used, here named Default. The PredefinedTypes
package is a standard package that contains pre defined types like int, bool etc.
Inside the Default package there are four classes; Dishwasher, DishwasherBuilder, FrontPanel
and Motor. A package can except classes also contain; types, variables, functions, events,
diagrams and dependencies to other packages. The big diagram on the picture is the state chart
diagram for the Dishwasher class. This state chart diagram consists of three in parallel
executing curse of events which on the picture are marked by the dotted line. One good thing
with Rhapsody is that you can animate the execution and watch how the program is jumping
between the states.
33 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 34 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.3.2 Interrupt Driven Framework (IDF)
IDF (Interrupt Driven Framwork) is a framework that replaces the operating system and makes
it possible to execute code made with Rhapsody outside of Windows. In this thesis work I
won’t be able to use an operating system because I can’t download an operating system onto
the CrossFire MX1 module and therefore I need to use this framework instead. It is I-Logix the
creators of Rhapsody that have made the IDF framework.
When Rhapsody generates code from a UML diagram it uses a certain number of already
created classes and functions that begins with the prefix OXF or OM. In Windows environment
these classes and functions uses the Windows API and comes with the Rhapsody installation,
but when the code needs to be compiled for target like CrossFire MX1 a framework that
replaces the Windows API is needed. See Figure 7.15 of what the IDF framework look like in
Rhapsody.
Figure 7.15 - IDF Package
34 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 35 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.4 CAN – Controller Area Network
7.4.1 Introduction
CAN is the acronym for Controller Area Network which is a standard for serial data
transmitting that was developed in the beginning of the 80s by the German company Robert
Bosch GmbH. The intention was to create a network that was robust and could tolerate
electromagnetic disturbances so that it could be used within the car industry. CAN has an
advanced mechanism for detection of corrupted data and can transmit data at speeds up to 1
Mbit in a distance of max 40 meters [26]. Longer transmitting distances is of course possible
but to the cost of lower speed.
Over the years the CAN standard have become more and more popular and can today be found
in almost every new car manufactured in Europe, where you in the most luxurious models can
find up to five separate CAN networks connecting over 50 different ECUs (Engine Control
Unit) [28]. Also a lot of other companies do use CAN in vehicles like trains and boats but also
in industrial control systems.
7.4.2 History
In the beginning of the 80s some engineers at Bosch investigated how they could use already
existing systems for serial bus transmitting in cars. They found out that none of the existed
systems fulfilled the demands made by the car industry and therefore in 1983 the development
of a completely new standard was started. Companies like Mercedez-Benz and Intel were early
involved in the development process of this new standard which name came to be Controller
Area Network., CAN [25].
During the SAE (Society of Automotive Engineers) congress in Detroit 1986 Bosch introduced
CAN for the first time. During the years that followed many seminars about this new
innovative communication protocol was held and the following year the first CAN card was
introduced, the Intel 82526. A few years later Bosch released version 2.0 of the CAN
specification which in year 1993 became ISO standardized (ISO 11898-1).
7.4.3 How the CAN protocol works
CAN is a communication protocol for serial bus transmitting where several nodes are
connected in a system. Systems connected through a CAN bus is a so called multi master
system which means that all the nodes in the system can send and receive data and all the
nodes can request the buss at the same time. The Can protocol is based on the OSI model
35 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 36 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
(Open System Interconnection Reference Model) which is a standard description of data
communication and network protocols. The OSI model is separating a protocols functions into
seven different layers. From the top to the bottom the layers are as follows; application layer,
presentation layer, session layer, transport layer, network layer, data link layer and the physical
layer [23]. Each layer does only communicate with the two closest layers, for example the
network layer does only communicate with the data link layer and the transport layer. The
CAN protocol does only cover the two lowest layers of the OSI model, that is the data link
layer and the physical layer and this means that the user is free to implement the remaining
layers himself. However existing CAN-based protocols that covers the remain layers does
exist, an example of such a layer is CiA:s own CANopen protocol.
The CAN protocol is a message oriented protocol and that means that the messages are defined
based on their content and not from where they were sent or where they are being transmitted.
In the beginning of each message there is a filed intended for identification of the message and
the content of this filed decides the priority of the message. As mentioned before all nodes may
request the bus at the same time and to decide which nod that should have access to the buss
first, a method called bit arbitration is used. This method means that each bit that is transmitted
on the bus is compared to the real value of the buss, if the values mismatch the node stop
transmitting. For example if two nodes are putting a “1” on the buss at the same time the value
of the buss will be “1” but if one of the nodes put a “0” the buss will have the value zero
because zero is the dominant bit. The node that sent the “1” will recognize this and wait for the
buss to be free again.
When sending data over a CAN buss the data is sent in the form of messages or even called
frames. A CAN frame has a defined format so that the receiver of the data know how to
interpret the information. Bellow is a picture (Figure 7.16 and Figure 7.17) of what a CAN
frame look like.
Figure 7.16 – Beginning of CAN frame.
For simplicity all parts of the frame is not described but only the most important parts that
surrounds the data part. The frame begins with a start bit, SOF (Start of Frame) and is followed
by an 11 bit long filed called the identification field. If a larger identification field is needed the
frames can be transmitted as extended. An extended frame supports an identification filed of 29
bits. A zero in the SOF field means start of new frame and the number in the ID-field decides
the priority of the frame. Lower numbers means higher priority because a zero is the dominant
bit. The DLC (Data Length Code) field specifies the size in bytes (0-8) of the transmitted data.
Figure 7.17 – End of CAN frame.
36 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 37 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Right after the data part is an error control (CRC) which is an cyclic redundancy check that is
used to verify if the data has been corrupt or not. The last part of the CAN frame is the EOF
(End Of Frame) which must consist of seven ones in series. The CAN frame does also contain
other smaller fields like ACK which is used to confirm that a previous frame have been
received correctly.
7.4.4 CANopen
The CAN protocol is very simply constructed and because of that there are other protocols
based on the CAN protocol that facilitates the handling of it so that the user doesn’t need to
handle CAN specific things like the different OSI layers. One such protocol is CANopen that
also have been developed by Bosch and is used by CC-systems. When I in this thesis work not
have been working with CANopen there is no idea to write more about it. Information about
CANopen can be found on the internet.
37 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 38 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.5 Tasking
Tasking is a development environment intended for
software engineers of embedded systems developed by the
company Altium Limited. The company itself claims that
the Tasking-tools are world leading within the areas of
software engineering and embedded systems [11]. The
development environment includes compilers, debuggers, RTOS support and support for 8, 16
and 32 bit CPUs. During the thesis work I’ve been using Tasking 8.5 release 2 because this
version has an embedded flash loading function.
There are two ways of using Tasking; one way is to use Tasking EDE (Embedded
Development Environment) which is Tasking’s own development tool. The other way and the
way I’ve been using is to call the Tasking compiler directly from Rhapsody without using
Tasking EDE. See Figure 7.18 for a screenshot of Tasking Embedded Development
Environment.
Figure 7.18 - Tasking EDE
38 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 39 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.6 CCSimTech
CCSimTech is the name of CC-System own developed simulation technology that can be used
for simulation of CAN based systems. This tool facilitates and improves the development of
embedded control and information systems that uses CAN networks. CCSimTech is the name
of a wide series of tools used for simulation of different embedded systems and below in
(Figure 7.19) is a screenshot showing what a simulation with CCSimTech and its tools may
look like.
Figure 7.19 - CCSimTech tools
7.6.1 Introduction to CCSimTech
CCSimTech can be used to replace hardware by simulating the presence of it. Thanks to this a
complete system can be simulated and tested on a single desktop PC. CCSimTech can also be
used to simulated parts of a system while the rest is real hardware and this facilitates the
development process for the software engineer. For software engineers it is not always sure
that he or she will have access to the hardware the software is intended for and in this case
39 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 40 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
CCSimTech can be used to simulate the presence of the hardware. Also other tools intended
for automated testing and debugging can be used to ensure that the application is working
correct.
The core in CCSimTech is the software components which are used to simulate the different
parts of a system. These components replace the drivers of the real target and simulate the
behaviour of for example CAN, IO, EEPROM and FLASH. By using Visual Studio for
example the developer can create new components like control panels, displays and physical
models which can be connected together with CCSimTech to simulate the behaviour of the
new hardware.
There are several benefits of using CCSimTech, for example the development of the software
may begin at start or even before the development of the hardware. An ordinary desktop pc can
be used as development platform instead of a complete target system which leads to shorter
development time. Maybe the greatest benefit is that all developers in a company do have full
access to the complete target system on their own computer and thereby they do not have to
share the same test bench.
There are three types of development environments that can be used when developing and
testing a system. The first type and the most common is called complete system simulation and
mean that everything is simulated on a single desktop pc. The second type is called mixed
simulation and means that some parts of the system are real hardware and the rest is simulated,
so called mixed simulation. The third and last type is called target hardware test and means that
all hardware is real and only some control panels are simulated on the pc.
Complete System Simulation
At complete simulation all nodes in a system are simulated on a single desktop pc. This
method is the most common because it’s the easiest and cheapest when no expensive hardware
is needed. Each part of the system is its own process and communicates through the same
interface as the real drivers
Mixed Simulation
Mixed simulation is used to verify that the communication between some nodes really works
because simulation only is not enough to guarantee correct result. If one for example wants to
simulate a CAN network where some parts are simulated and some parts are real a CAN card
can be connected to the desktop pc.
Target Hardware Test
At target hardware test all the nodes in the system are real hardware components and only the
control panels may be simulated on a pc. This kind of test requires that the hardware is
connected to special cards in the computer like a CAN card for example.
40 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 41 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
As mentioned before CCSimTech consists of several different simulation tools. Two of these
tools are called IOTool and BusTool and were very useful during this thesis work. In the
following sections these tools are described further.
7.6.2 IOTool
IOTool is a tool that is used to supervise IO ports and their values. By using IOTool a
developer can see if all ports were create correctly and if the values are correct. The user does
also have the option to set values on a port directly from IOTool; this is useful if one wants to
set and test different values on some ports. In this thesis work I have been using IOTool a lot to
test my applications. See Figure 7.20 for a screenshot of IOTool from one of the simulations
with my CrossFire software.
Figure 7.20 - IoTool
41 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 42 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
7.6.3 BusTool
BusTool is another useful CCSimTech tool that is used to supervise and send packages over
CAN or LIN networks. With help of BusTool supervising of packages sent on the bus is no
problem. If you want you can even transmit messages directly from BusTool and test how your
application handles incoming messages. In the setting for BusTool you can specify what CAN
network you are connected to and what baud rate you’re using. These setting must match the
application you have developed or otherwise not much will happen. During this thesis work
I’ve been using BusTool a lot both for simulation and for test against target (CrossFire MX1).
Figure 7.21 is a screenshot from the simulation of my CrossFire software where CAN
messages are being transmitted and received.
Figure 7.21 - BusTool
42 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 43 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
8 CROSSFIRE MX1
Figure 8.1 - CrossFire MX1
CrossFire MX1 (Figure 8.1) is the name of an IO module and controller developed by CCSystems and intended for use in tough environments [5][7]. The module is intended for use in
decentralized systems, that are systems with several nodes (see Figure 8.2) that handles their
own task without relying on a master unit. CrossFire MX1 is a so called CAN bus node and
supports the CANopen protocol which is one of the leading protocols for CAN bus networks.
Figure 8.2 - CrossFire Nodes
43 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 44 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
To be able to handle all the strains this kind of module can be exposed to CC-Systems have
used their experiences from the military. The module is constructed to handle a wide spectra of
power supply (10V to 36V up to 3A) and can operate in environments where the temperature
may shift from -40 to 85 degrees Celsius [5][7]. Silicone moulding ensures that the CrossFire
MX1 is well protected from dirt, wet and shocks. The module is also EMC certified (ISO
14982 for emissions and ISO 11452-2 for immunity) [6] which means that it is durable to
electromagnetic emissions and doesn’t cause such emissions. The different parts of the
CrossFire module have been carefully selected, for example the powerful coating and the M12connectors which are specially designed for tough mobile applications.
The CrossFire MX1 consist of 8 do called M12 connectors of type female. The large contact is
a M23 connector intended for power supply and flash loading. The module does further have
two M12 connectors of type male which are intended for CAN and ID. A wide range of
languages and development tools can be used to develop applications for the CrossFire [6],
here are a few examples.



C/C++ with tools like Tasking or Keil Microvision.
UML with tools like I-Logix Rhapsody
IEC 61131-3 with tools like CoDeSys
The CrossFire MX1 can with its 16 different ports be configured in many different ways, here
are some examples:
A
PWM: 8
Digital Out: 4
Digital In: Analog In: 4
Frequency In: -
C
PWM: 2
Digital Out: 6
Digital In: 2
Analog In: 4
Frequency In: 2
B
PWM: 4
Digital Out: 4
Digital In: 4
Analog In: 4
Frequency In: -
D
PWM: Digital Out: 8
Digital In: 2
Analog In: 4
Frequency In: 2
*PWM = Pulse Width Modulation, equal to Analog Out.
44 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 45 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Data Sheet for CrossFire MX1b:
(The following data is taken from the product description for the CrossFire MX1) [5]
Kernel
Processor
Compact Flash
RAM
Infineon C167CR
2 x 256 kB. OPTION: 2 x 512 kB
256 kB
Serial Interfaces
CAN
COM
Drivers: Phillips 82C251 or 82C252
RS232
Analog Inputs
Range
Resolution
Reference voltage
0-5, 0-35 V or 4- 20 mA
10 bit
5 V, separate feed per input
Digital Outputs
Current, max.
Control and protection
PWM Outputs
Current, max.
Control and protection
Environment
IP-class
Temperature range
EMC conformity
3,0 A
» Status feedback
» Short circuit protected
3,0 A
» Current controlled
» Short circuit protected
IP67
-40 °C - + 85 °C (operating)
ISO 14982 for emissions
ISO 11452-2 for immunity
Power
Voltage
10 - 36 VDC
Connectors
I/O and serial
Power supply
DIN M12
DIN M23
Miscellaneous
Diagnostics
LED-indicators
Node ID
Digital with 16 positions
Table 8.1 – Data Sheet CrossFire MX1b
45 (90)
Rhapsody on microcontrollers
9
Thesis worker
Doc Nr
Claes Paulsson
Page 46 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
DRIVERS FOR CROSSFIRE MX1
For CrossFire MX1 there does already exist working drivers for IO, CAN, EEPROM,
FLASH, RS232 (Serial port), Timer etc. In this thesis work I have only used the drivers for IO
and CAN and in this chapter the interface for these drivers are described.
By using the drivers for IO you can read and write values to the ports of the CrossFire and by
using the CAN drivers you can communicate with the module through a CAN network. The
drivers can be downloaded and stored locally on the hard drive. When the drivers are
downloaded to the hard drive they are stored in a folder structure similar to the picture below
(Figure 9.1).
Figure 9.1 – The drivers
In the tables below (Table 8.1 and Table 8.2) a list of explanations on files that belongs to IO
and CAN is shown.
Drivers for IO
Filename
HAL_Io.h
HAL_Io_HwDefs.h
HAL_IoCfg.c
hal_io.lib
HAL_IO.lib
Description
Interface
Definitions of structures, types, defines etc.
Configuration, initialization of variables.
Static Linked Library intended for the Tasking compiler, i.e.
compiling against target
Static Linked Library intended for the Visual Studio
compiler, i.e. compiling for simulation
Table 9.1 – Drivers for IO
46 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 47 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Drivers for CAN
Filename
can.h (Target)
can.h (Simulering)
candefs.h
candrv_public.h
cancfg.h
cancfg.c
canTimer.h
hw82527.h
hw82527Spi.h
hwc167.h
canl.lib
hal_spi.lib
can.lib
candbg.lib
Description
Interface, Target specific
Interface, only for simulation
Definitions of structures, types, defines. Target only
Definitions of structures, types, defines. Simulation only
Configurations, defines, structures, types etc.
Configuration, initialization of variables, interrupts.
Interface for Timer handling
Hardware specific 82527 (CAN card)
Hardware specific 82527 (CAN card)
Hardware specific C167 (CPU)
Static Linked Library intended for the Tasking compiler, i.e.
compilation against target.
Static Linked Library intended for the Tasking compiler, i.e.
compilation against target.
Static Linked Library intended for the Visual Studio
compiler, i.e. compilation for simulation.
Static Linked Library intended for the Visual Studio
compiler, i.e. compilation for simulation.
Table 9.2 – Drivers for CAN
47 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 48 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
9.1 Description of IO and CAN driver interface
The interface for the CrossFire MX1 drivers is the function specifications that exist for each
driver and in this chapter a more detailed description of the CAN and IO interface is made.
9.1.1 IO
The interface for the IO drivers is specially constructed to fit the hardware of the CrossFire
MX1. The interface does only consist of five functions which all begin with the prefix HAL_.
This prefix tells the programmer that the interface is a so called Hardware Abstraction Layer
interface, i.e. a shell that facilitates the programming by being specifically developed
according to the properties of the CrossFire. The original drivers for the C167 processor
family has far more functions and possibilities than the CrossFire module can handle and
therefore have CC-Systems developed their own drivers which both facilitates the
programming but also prevents unnecessary errors to occur.
The IO interface consists of the following five functions:
 HAL_IOInit
 HAL_IOSetProperties
 HAL_IOGetProperties
 HAL_IOSet
 HAL_IOGet
The HAL_IOInit function is used for initialization of all the ports of the CrossFire Module.
This function must be called before any other function. At the initialization all ports are
initialized according to their default values. Which values a port may have can be read about
on appendix IO Portar.doc (Swedish version).
HAL_IOSetProperties is the function to call if a property of a port needs to be changes. All
ports have several different properties that can be change according to ones desire. However
the ports differ and all properties are not selectable for every port. See appendix IO
Portar.doc for more detailed information.
HAL_IOGetProperties is called to get the value of the different properties for a specific port.
The HAL_IOSet function is used to set a value of an out port. A port can for example be
configured as analogue out or digital out.
HAL_IOGet is used to read the value of a specific in-configured port.
48 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 49 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Detailed view of IO interface
unsigned char HAL_IOInit(
void
)
unsigned char
HAL_IOSetProperties(
unsigned short channel,
unsigned short propertyIndex,
unsigned short propertyValue
)
unsigned char
HAL_IOGetProperties(
unsigned short channel,
unsigned short propertyIndex,
unsigned short * propertyValue
)
unsigned char
HAL_IOSet(
unsigned short channel,
unsigned short
value
)
unsigned char
HAL_IOGet(
unsigned short channel,
unsigned short * value
)
Explanations to the attributes
All functions are returning an ”unsigned char” which is a code that specifies if the
function call was succeeded or if it failed, in that case the value does also identify the error.
channel:
propertyIndex:
propertyvalue:
value:
Specifies the port.
Specifies the property.
Specifies the new value or where the value should be stored.
Specifies the new port value or where the read value should be
stored.
49 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 50 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
9.1.2 CAN
The interface of the CAN drivers is more general and follows and international standard and
therefore no HAL (Hardware Abstraction Layer) interface is needed. The current CAN drivers
have two interfaces, one intended for target and one intended for simulation with
CCSimTech.
The CAN interface for target consists of the following 15 functions:















CanOpen
CanClose
CanSend
CanSendEx
CanReceive
CanReceiveEx
CanPurgeComm
CanAddRemoteReply
CanRemoveRemoteReply
CanGetStatistics
CanGetLastTimeStamp
CanGetCurrentTimeStamp
CanGetLastError
CanSetBaudrate
CanGetBaudrate
Only the functions used in this thesis work is described.
The CanOpen function creates a Handle to a CAN net. This function must be called before
any other CAN function.
CanClose is the opposite of CanOpen and is called when the application no longer need
access to the CAN net.
CanSend is used to send message of standard type on the buss. CanSendEx can be used to
send extended frames.
CanReceive is called to receive frames on the CAN bus.
50 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 51 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Detailed view of the CAN interface (Target)
CanHandle CanOpen(
const char *pNetName
)
int CanClose(
CanHandle hInterface
)
int CanSend(
CanHandle hInterface,
CanMsgId id,
unsigned char *pData,
unsigned char dataLength,
int bRtr
)
int CanSendEx(
CanHandle hInterface,
CanMsgId id,
unsigned char *pData,
unsigned char dataLength,
int bRtr,
CanFrameType frameType
)
int CanReceive(
CanHandle hInterface,
CanMsgId *pId,
unsigned char *pData,
unsigned char *pDataLength
)
int CanReceiveEx(
CanHandle hInterface,
CanMsgId *pId,
unsigned char *pData,
unsigned char *pDataLength,
CanFrameType *pFrameType
)
int CanPurgeComm(
CanHandle hInterface,
CanPurgeAction action
)
int CanAddRemoteReply(
CanHandle hInterface,
CanMsgId id,
unsigned char *pData,
unsigned char dataLength
)
int CanRemoveRemoteReply(
CanHandle hInterface,
CanMsgId id
)
int CanGetStatistics(
CanHandle hInterface,
CanStatistics *pStatistics
)
int CanGetLastTimeStamp(
CanHandle hInterface,
CanTimeStamp *pTimeStamp
)
int CanGetCurrentTimeStamp(
CanTimeStamp *pTimeStamp
)
CanErrorCode CanGetLastError(
void
)
int CanSetBaudrate(
CanHandle hInterface,
unsigned long baudrate
)
int CanGetBaudrate(
CanHandle hInterface,
unsigned long *pBaudrate
)
51 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 52 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Explanations to some of the attributes
All functions except CanOpen returns an int. CanOpen returns a CanHandle which is a
Handle to a CAN net. For the other functions TRUE ”1” is returned or FALSE ”0” depending
on if the function succeeded or not.
hInterface:
Id:
pData:
dataLength:
bRtr:
frameType
A Handle to the CAN net.
Specifies the identification number of the frame.
A pointer to a 8 byte large array that contains the data to send or
receive.
Specifies the size of the data expressed in bytes (1-8).
Tells if the frame is of the type Remote Frame or not.
Standard or Extended frame.
The CAN interface for simulation consists of the following 13 functions and belongs to the
simulation technology CCSimTech.














CanOpen
CanOpenEx
CanClose
CanSend
CanSendEx
CanReceive
CanReceiveEx
CanAddRemoteReply
CanRemoveRemoteReply
CanEnumRemoteReply
CanGetStatistics
CanGetLastTimeStamp
CanGetCurrentTimeStamp
CanGetDeviceHandle
These functions are very similar to the functions for target but some of them differ in the
number of attributes. One different is that the attributes pData and Id have been united into the
parameter pCanMsg.
52 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 53 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Detailed view of the CAN interface (Simulation)
CANAPI CanHandle
CanOpenEx(
LPCTSTR pNetName
);
CANAPI CanHandle
CanOpen(
LPCTSTR pNetName
);
CANAPI BOOL
CanClose(
CanHandle hInterface
);
CANAPI BOOL
CanSend(
CanHandle hInterface,
CanMsg *pCanMsg,
DWORD dataLength,
BOOL bRtr
);
CANAPI BOOL
CanSendEx(
CanHandle hInterface,
CanMsg *pCanMsg,
DWORD dataLength,
BOOL bRtr,
CanFrameType frameType
);
CANAPI BOOL
CanReceive(
CanHandle hInterface,
CanMsg *pCanMsg,
LPDWORD pDataLength,
CanMsgId *pCanMsgSel,
DWORD milliseconds
);
CANAPI BOOL
CanReceiveEx(
CanHandle hInterface,
CanMsg *pCanMsg,
LPDWORD pDataLength,
CanMsgId *pCanMsgSel,
CanFrameType frameTypeSel,
CanFrameType *pFrameType,
DWORD milliseconds
);
CANAPI BOOL
CanAddRemoteReply(
CanHandle hInterface,
CanMsg *pCanMsg,
DWORD dataLength
);
CANAPI BOOL
CanRemoveRemoteReply(
CanHandle hInterface,
CanMsgId id
);
CANAPI DWORD
CanEnumRemoteReply(
CanHandle hInterface,
ULONG index,
CanMsg *pCanMsg,
LPDWORD pDataLength,
CanFrameType *pFrameType
);
CANAPI BOOL
CanGetStatistics(
CanHandle hInterface,
CanStatistics *pStatistics
);
CANAPI BOOL
CanGetLastTimeStamp(
CanHandle hInterface,
CanTimeStamp *pTimeStamp
);
CANAPI HANDLE
CanGetDeviceHandle(
CanHandle hInterface
);
53 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 54 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10 RHAPSODY ON MICROCONTROLLERS
The main task with this thesis work is to perform a study where the drivers to the CrossFire
MX1 are integrated in a Rhapsody project. I’m also supposed to investigate how the interface
and architecture most suitable can be designed. In this chapter I ‘m describing how this study
has be performed, problems occurred and solutions. In the end of this chapter I present the
results.
10.1 Description of the study
This study has been divided into three parts. In the first part I needed to do some research and
investigate how the architecture and interface should be designed so that functionality and
usability could be combined in the best way. I had two proposals on the desk that were
compared with each other to find out advantages and disadvantages. The second part of this
study was to integrate the CrossFire MX1 drivers in Rhapsody according to the proposals from
the first part. During this part of the study it would be shown if it was possible to integrate the
drivers according to the proposals from part one. The third and last part of this study was to use
the integrated drivers practically to verify that everything worked correct. In this part of the
study I had to create a new Rhapsody project named Demonstrator that imported the driver
packages from part two and used them. This demonstrator would later then be tested in both a
simulated environment and on the real target (CrossFire MX1).
10.2 Problems
During the beginning of this study the purpose was to investigate how the architecture and
interface in the best way could be designed. Here one had to know what in Rhapsody that
could be done and what couldn’t. I also had to do some research to figure out how a future
developer wants to use the drivers. One condition to succeed with this part of the study was to
know about the drivers and what the interfaces looked like. Another question on the table was
if a future developer of CrossFire MX1 should be able to see all part of the drivers or just the
interfaces.
10.3 Analysis
10.3.1 The Drivers
One part of this study was to get to know the drivers of the CrossFire MX1, this because it is of
great importance to know how the drivers are designed if one wants to make a good solution.
As mentioned before I have in this thesis limit me to only work with the CAN and IO drivers
and in this section a concise analysis of these drivers are presented.
54 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 55 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
What’s in common for these drivers are that both consists of a header file that contains the
interface, i.e. the file contains a specification of all the functions that can be used by the
developer. This interface header file does also include another header file that contains
definitions of types, structures etc. Further the drivers do also consist of a c-file which contain
some sort of configuration, for example initialization of variables. This c-file does in some
cases (CAN) include other interfaces. One another similarity with the drivers are that they
consist of two static linked libraries, one intended for simulation in Windows environment and
one intended for target. Summarized one can say that the drivers consist of two header files,
one c-file and two static linked libraries.
The difference between these drivers is that the interface of the IO drivers is the same for both
simulation and target. The CAN drivers however do use different interfaces for simulation and
target, said can be that these drivers are quite similar.
10.3.2 Interface & Architecture
One of the main tasks with this thesis work was to investigate how interface and architecture
should be designed so that functionality and usability could be combined in the best way. One
condition to succeed with this was to know the project environment of Rhapsody and therefore
a few weeks was spent studying software development with Rhapsody. I did also have the
opportunity to study to real Rhapsody projects and se how the interface and architecture were
constructed in these projects. I did also gain some valuable tips and propositions from Anders
Öberg at CC-Systems.
10.4 Solution
In the second part of the study I prepared different proposals of what the Rhapsody project
could look like. The keywords during this work have always been functionality and usability
with emphasis on usability.
.
10.4.1 Proposal 1
The first proposal was to collect all the drivers in own packages with descriptive names like
CAN and IO. All these packages should belong to a package called DriverPkg. Since the CAN
drivers do use different interfaces for target and simulation it felt sensible to divide each driver
package into two sub packages called SIM and TARGET. In this way the drivers for
simulation would be separated from the drivers for target. See Figure 10.1. For these packages
the idea was that only the interface and configuration should be visible for the developer all
other files should be hidden.
55 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 56 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
The idea with this solution was that a future developer easily would be able to import the entire
driver package (DriversPkg) and in the list Scope of the component select what specific drivers
he or she needs and if they are intended for simulation or target. In this solution the idea was
also that all static linked libraries that belonged to the drivers should be integrated in the
packages and all necessary settings should be made in stereotypes inside the packages.
Stereotypes are a refinement in Rhapsody where the user may enter a specific configuration
and give the configuration a descriptive name after the user can apply the stereotype on the
component configuration. In this proposal the idea was that there should be one stereotype with
setting intended for simulation and one stereotype with settings for target.
The basic idea with this solution is that it is very user friendly and it does also separate the
interfaces for target from the interfaces for simulation. The solution is user friendly because all
a user needs to import to his/her own project is the package DriversPkg. After that the user can
select what drivers he/she needs and specify if the drivers are intended for target or simulation.
The drivers do require some settings for compilation and linking and to spare the developer
from dealing with these setting two stereotypes with working configurations are include in the
packages.
Figure 10.1 – Drivers packages, proposal 1
56 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 57 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.2 Proposal 2
The second proposal is entirely based on the first one but here the solution has been change a
bit to make it even more user-friendly. A problem discussed was the different interfaces for the
CAN drivers. The thing is that the drivers for simulation and target should have the same
interfaces but different implementations. One main thought behind the CCSimTech simulation
technology is that a user of it easily should be able to switch between the simulated
environment and the real one. The way the drivers are designed now changes in the code is
needed every time a switch from simulation to target is made or vice versa. In this way a
developer can never guarantee that an application really works if he or she has to do
modifications in the code after every successful simulation.
Since the different CAN interfaces were quite similar a workaround in the form of a new
interface could be done. The new simulation interface was identical to the interface for the
target but called the functions for simulation or target depending on what compiler directive
that were defined (SIMULATE or TARGET).
In the second proposal the separation of the drivers into SIM and TARGET is removed, see
Figure 10.2.
Figure 10.2 – Drivers package, proposal 2
57 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 58 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.3 Integration of proposal 1
The integration of proposal one was made in such way that all files that should be modifiable
from within the Rhapsody project were include with the Revere Engineering tool. For the IO
and CAN drivers it is only the configuration file that a developer needs to modify and thus the
only file that needs to be generated by Rhapsody.
There are two main ways of including files in a Rhapsody project, one way is to take the code
from the file and store it in packages and that means that the code will be generated by
Rhapsody. The other way is to add the files to the project as external which means that the files
should not be generated instead the files will only be compiled by the compiler.
The developer does also need to know the interface of the drivers but the interface should not
be modifiable which means that the file is include as external. The remaining files should be
hidden for the developer and are therefore included by #include in the source code. The static
linked libraries have also been added as external and the idea is to link the files with the linker.
Finally necessary settings like compilation and linker directives have been stored in stereotypes
so that the developer easily can apply these on his/her application. For amore detailed
description of the integration of this proposal see appendix (Integrering av drivare i
Rhapsody.doc).
See Figure 10.3 and Figure 10.4 for a picture of proposal 1.
Figure 10.4 - IO package, proposal 1
Figure 10.3 - CAN package, proposal 1
58 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 59 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.4 Integration of proposal 2
The integration of proposal two did principally follow the procedure from the integration of
proposal one with some minor differences. The main purpose of proposal two was to skip the
separation of the files into the packages SIM and TARGET and instead only have the drivers
separated as CAN and IO. To succeed with this changing it required that the drivers had the
same interface for both simulation and target. Therefore a wrapper file was constructed that
used the interface for target but depending on compilation directives (SIMULATE or
TARGET) called the functions for simulation or target. For amore detailed description of the
integration of this proposal see appendix (Integrering av drivare i Rhapsody.doc).
See Figure 10.5 for picture of proposal 2.
Figure 10.5 - Proposal 2
59 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 60 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.5 Problems
During testing of proposal one and two problems occurred that led to a major revision of the
proposals, which later resulted in the final solution.
Problem 1
The first problem occurred when I tried to link the static linked libraries. It turned out that it’s
not possible to have these files placed inside packages; instead these files must be included in
the configuration for the active component. An alternate solution had been to refer to the static
linked libraries by using stereotypes but here problem number two occurred.
Problem 2
As long as no settings except the default are made in the configuration Rhapsody has no
problems in using settings made in stereotypes. But as soon as a minor change is made in the
configuration Rhapsody considers the settings in the configurations to be the most current and
ignores the settings made in the stereotype. Setting must be allowed to be done in the
configuration and thus the idea of using stereotypes won’t work.
Problem 3
Problem number three did actually occur during the integration of the CAN configuration file,
but because of incorrect settings Rhapsody did not inform about it. Implemented in the
configuration file are a number of tasking-specific interrupts and Rhapsodys’ Reverse
Engineering function has no idea of how to deal with these code lines; the result is that these
code lines are ignored. The solution to this problem was to manually add the missing
interrupts.
Problem 4
Problem number four came as a consequence of problem number three. It turned out that some
of the functions executed by the interrupts were using variables generated by Rhapsody.
Rhapsody has in built-in order of how variables, functions and types should be generated and
this order can’t be changed. Rhapsody will first generate types then functions and finally the
variables. Since some functions are using the variables and requires the variables to be
initialized a compilation error occurred. However this problem could be solved by doing some
minor adjustments in the code.
As a consequence of these problems I had to redesign my solution, but I got some valuable
inputs from Dag Erlandsson at the company Nohau in Malmö.
60 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 61 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.6 Final solution
In the final solution (see Figure 10.6) the files are separated in the packages Configurations and
Interfaces, this since the interface files never should be generated by Rhapsody. Another big
difference is that the settings and the static linked libraries have been placed in the
configuration for the active component. With this solution a future developer will need to
import not only the driver packages but also the component with the necessary settings. One
way could be that a developer is using this component as a foundation for software
development or manually copies the setting to his/her own configuration. This solution is not
as user friendly as the introductive proposals but based on what’s possible to do with Rhapsody
this is probably the best.
Figure 10.6 – Final solution
61 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 62 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.4.7 Settings for compilation and linking
The following settings are made for compilation/linking with Tasking 8.5 release 2.
Setting for compilation
$(CCFLAGS) -DIDF -x2 -DCPUTYPE=0x1662 -DUseNullBlockContainter
-DTARGET -D__cplusplus -I..\..\Idf_Component\Tasking\
-I..\..\Idf_Component\Tasking\oxf\ -I..\..\Tasking_Component\Tasking\
-I..\..\ -w66 -w68 -w91 -wstrict -znocustack --embedded
$OMCPPCompileCommandSet
Settings for linking
-cf -c++ -M$(model) -x2 EXTEND2 SUMMARY LIBPATH($(LIB)) \
NOWA(176) \
NOWA(118) \
NOCC \
LP('c:\program\tasking\c166_v8.5\lib') \
GENERAL \
RE(ME(0F200h-0F5FFh)) \
IS(2048) \
ME(ROM(0h-07fffh,10000h-9FFFFh)) \
ME(RAM(200000h-280000h)) \
SS(C166_US(+10000)) \
HS(64000h) \
RE(SY(0)) \
RE(ME(0EF00h-0EFFFh)) \
RE(ME(0FCC0h-0FCDFh,0200h-0BFFh)) \
LRG \
PL(60) \
PW(132) \
$OMLinkCommandSet
The following settings are made for compilation/linking with Visual Studio 6.0
Settings for compilation
/I . /I $OMDefaultSpecificationDirectory /I $(OMROOT)\LangCpp /I
$(OMROOT)\LangCpp\oxf /nologo /W3 /GX $OMCPPCompileCommandSet /D "_AFXDLL"
/D "WIN32" /D "_CONSOLE" /D "_MBCS" /D "_WINDOWS" /D "SIMULATE"
$(INST_FLAGS) $(INCLUDE_PATH) $(INST_INCLUDES) /c
Settings for linking
$OMLinkCommandSet /NOLOGO /NODEFAULTLIB:LIBCD.lib user32.lib
62 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 63 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
10.5 Results
To verify that the integration of the drivers succeeded ant that the created drivers packages can
be used by rhapsody to program the CrossFire MX1 module I developed a demonstration
application. The demonstration application is developed as a separate Rhapsody project where
the drivers and components have been imported. The development of the demonstrator can be
read about in chapter 11.
The result of this study proves that the drivers for CrossFire MX1 can be integrated and used
by Rhapsody. In the beginning of the test phase some problems with settings in the make-file
and some problems with the flash loading of the CrossFire module did occur. More about these
settings and how the flash loading works can be read about in chapter 13 (Flash loading of the
CrossFire MX1).
After succeeded to generate a working hex-file and download it to the CrossFire unit some
minor problems occurred. An incorrect setting caused a watchdog to reset the application every
hundred millisecond and a hardware related error in the test equipment made the CrossFire
register Open Load causing the unit to automatically shutoff some ports. After correcting the
problem with the watchdog and adding some effect resistors to the testing equipment the
problems disappeared and the testing of the unit worked pretty well and the results from the
simulation and the real test did match. With this study I have succeeded to fulfil the
requirements Rs1, Rs2 and Rw4 from chapter 3.
63 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 64 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
11 THE DEMONSTRATOR
In parallel with the work of integrating the driver of the CrossFire module in Rhapsody I also
worked with the development of the demonstrator (according to requirement Rs3) that should
use the driver packages in Rhapsody and thereby verifying that every thing worked correct.
Besides the demonstrator I did also develop a control panel for controlling of the demonstrator
and a graphical application for simulation of the testing equipment.
11.1 The creation of the demo project
The purpose of the third and last part of this study was to develop a demo project in Rhapsody
that imported the completed driver packages and used them to verify the implementation and
prove that everything worked as planed.
The idea with the demo project was that a user should be able to communicate with the
CrossFire unit from my control panel through the CAN network (according to requirement
Rw1). The user should be able to send and receive data and have the possibility to change all
the setting supported by the drivers according to requirement Rw2. Before I begun the
development of the demonstrator I developed two other applications in Visual Studio 6.0
which I used to control and simulate the expected behaviour of the CrossFire MX1. The first
application, the control panel (see Figure 11.5 section 10.2) was used to send commands to the
CrossFire through the CAN-bus. The other application called CrossFire MX1 I/O (see Figure
11.6 section 10.3) was used to show and change values of the ports of the CrossFire MX1. This
application was designed to look like the test box that I also constructed. The test box was used
in the real test of the CrossFire and more how it is constructed is shown in appendix
Kopplingsschema för Testbox.ppt.
The procedure applied during the creation of the demo project was intended to be identical to
the procedure applied by a future developer. From my new-created Rhapsody project I
imported the driver packages for CAN and IO as well as the IDF framework Also, components
for the Tasking compiler and the IDF framework were imported, this because they contained
necessary setting about compilation and linking of the packages. After that, I created a new
package called AppDemo and inside this package I created two classes, one class for dealing
with CAN (named GetCommands) and one class for dealing with IO (named CheckIO). For
each class I added a state chart diagram, see Figure 11.2 for state char diagram of the IO class
and see Figure 11.3 for state chart diagram of the CAN class.
When the demo project was completed it looked like the Figure 11.1.
64 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 65 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 11.1 - CrossFire MX1 demonstrator
Figure 11.2 – State chart diagram of class IO class
65 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 66 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 11.3 – State chart diagram of CAN class
For each state I implemented code to for example initialize the system, read the CAN bus or
check the values on the ports of the CrossFire. The reason to why I created two different
classes with own state chart diagrams are that Rhapsody will create two separate threads
independent of each other. This is good because then the demonstrator will be able to supervise
the ports and the CAN bus in parallel.
The purpose of the demonstrator is to show that the integration of the drivers has succeeded
and that the completed Rhapsody project really works in a simulated environment and against
target. Both the control panel and the demonstrator were necessary to perform a simple and
understandable demonstration. The graphical IO application was only create for simulation of
the testing equipment (the test box) that I also created. When the demonstrator is executed in a
simulated environment it is represented as a black console window, see Figure 11.4.
66 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 67 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 11.4 – The Demonstrator simulated
The demonstrator is developed as a separate Rhapsody project - the way a future customer is
supposed to. For the demonstrator project I have imported the driver package for the CrossFire
MX1 and the configuration settings. The demonstrator mainly consists of two threads. De task
of the first thread is to check the CAN-bus for incoming messages, interpret the messages,
perform the commanded IO operations and respond wit ha new CAN message. The task of the
second thread is to supervise the ports of the CrossFire and respond with a CAN message if a
ports value is changed.
If a CAN-message is received the identification number of the messages is first verified. What
id a CAN-frame should have and how to data is interpreted is up to the developer to define. In
my case a header file containing definitions of commands and values was created and by
including this header file both the demonstrator and the control panel knows how to interpret
the data.
After the id-number has been accepted the rest of the message is read and depending on the
content the demonstrator will perform different kinds of IO operations and respond with a new
message. For example the demonstrator may receive a request of changing a property of a port.
The first byte in the CAN frame does contain a unique number that specifies the request; the
second byte contains the id of the port the request applies to. The remaining bytes do contain
other necessary information depending on the specific request.
67 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 68 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
11.2 The Control Panel
Figure 11.5 - CrossFire MX1 Control Panel
The purpose of the Control Panel (Figure 11.5) is to facilitate the testing of the CrossFire and
its functions both in a simulated environment and against target. With the control panel the
user will be able to communicate with the demonstrator through the CAN bus according to the
requirement Rs4. The application is developed in Visual Studio 6.0 as an MFC project and
does contain graphical object like buttons, popup menus where a user easily man control and
supervise all the functions supported by the drivers of the Cross Fire module. The alternative to
the control panel would have been to use BusTool which is a part of CCSimTech. The problem
with BusTool is that all data must be written as numbers in fields that corresponds to the data
field of the CAN-frame. This is a very ineffective way of sending commands because it
requires that the user has access to a specification of all the commands and its syntax.
11.3 The Testing equipment
To be able to test the CrossFire unit in real I had to create a simple test box (according to
requirement Rs5) made of light emitting diodes, switches and potentiometers. This box was
connected to the CrossFire MX1 and by using the switches and potentiometers I could send
digital and analogue signals to the CrossFire. Received signals were represented on the diodes.
For further details of how the test box were constructed see appendix Kopplingsschema för
Testbox.ppt.
To be able to simulate this test box I developed a graphical application in Visual Studio 6.0
(see Figure 11.6) that resembles the test box.
68 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 69 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 11.6 – Simulated test box
With this application I can receive digital signals on the ports 1 to 8 (Green LEDs) and receive
analogue and digital signals on ports 13, 14 and 16 (Red LEDs). I can also send digital signals
with the switches on ports 11 and 15 as well as sending analogue signals by using the
potentiometers on ports 9, 10 and 12. By using this program it gets a lot easier to read the
values of the ports. The alternative to this application would have been to use IOTool but in
that case all values would have to been entered and represented as numbers.
With this application I was able to simulate the behaviour of the test box according to
requirement Rs6. The simulated behaviour and the real test did match and thereby fulfilling the
requirement Rs7.
11.4 Requirements and functions verified by the demonstrator
The main requirement verified by the demonstrator is that a developer is able to create a
working Rhapsody project that uses the driver of the CrossFire MX1. In my case it is the
console program (Figure 11.4) in the top of this chapter that is created by Rhapsody and that
uses the driver packages to control the CrossFire.
In addition to this requirement there are also a number of functions verified by the
demonstrator. See the list below.
IO:






Initialization of the ports (IO)
Reading of value of a port
Changing of value of a port
Reading of property of a port
Changing of property of a port
Reading of status of a port
CAN:





Connection to the CAN-bus
Disconnection from the CAN-bus
Sending of CAN message.
Receiving of CAN message
Reading of status of the CAN-bus
69 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 70 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
12 MODEL BASED DEVELOPMENT VS TRADITIONAL
In this chapter a comparison between Rhapsody, Visual Studio and Tasking is made. The
purpose is to investigate advantages and disadvantages of using a model based development
tool for software development.
12.1 Background
The background for this comparison is that there is common interest among companies that
wants to know the benefits of using a model based development environment like Rhapsody
instead of using more traditional development environments like Visual Studio and Tasking.
This chapter is separated into two sections where I in section one am presenting results from a
study made by SAAB Technologies and Combitech Systems. In section two I’m comparing
Rhapsody against Visual Studio and Tasking and discussing the advantages and disadvantages
of these development platforms. In this section I am also presenting my own experiences of
working in these environments.
12.2 Comparison Rhapsody vs traditional development methodology
Here a comparison of a project developed both model based and traditional by SAAB
Technologies is given. The comparison has been made by the company Combitech Systems
[29].
SAAB Technologies was assigned to develop a system for a customer X. This system should
consist of several nodes and in the article these nodes were named node A and node B. Of
reusing reasons it was decided that node B should be based on an already known hardware
platform while the requirements for node A required the development of completely new
hardware and software. The development of these nodes was separated into two projects,
project A for node A and project B for node B. The developers of the projects were the same. It
was decided that project A should be a pilot project where the developers should use a model
based development environment. They chose Telelogic Rhapsody as development tool.
In the end of these projects the developers realize the similarities between the projects and
decide to make a comparison to investigate what development method that is the best for the
development of their software.
Unfortunately no information regarding the functionality of the system and its nodes could be
found. The available information can be found in the following tables (Table 12.1, Table 12.2
Table 12.3).
70 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 71 of 90
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
CPU
OS
Language
Tool chain
Sec class
Node A
Node B
Hitachi H8S2633 (256kB flash, 16kB RAM, 22.11MHz)
RTXC 3.2c
Own-developed OS
C++
C and Assembler
Rhapsody 4.2 and Hitachi
IAR EW 1.53
Workshop 2.1
Table 12.1 – Specifications of Node A and Node B
The reason for why SAAB decided to do a comparison was because of the functional
similarities between the nodes (see Table 12.2).
Functional differences
Functional similarities
Node A
Two buttons
Node B
CAN-interface
Operator status
Communication protocol
Several flashing LEDs
Two serial ports
Control of external function in network
Measurements of load
Table 12.2 – Functional similarities
Results from the comparison are showed in the table below (Table 12.3).
Performance
Development time
Introduction of specific change
No of internal versions to first test
Node A
Max load 5 %
~ 250 h
~ 15 min
~ 15
Node B
Max load6 %
~ 800 h
~4h
~ 80
Table 12.3 - Results
The conclusion made by SAAB technologies is that there was a lot to gain by using a code
generating tool; the development time decreased to less than a third, the number of internal
versions was heavily decreased and the time to perform a specific change was only a fraction
of earlier times.
The drawback of using Rhapsody was first of all the threshold a developer had to overcome
before he or she can use Rhapsody and UML in an effective way. Also the price of the toll was
very high.
The benefits of using code generation were in front of all that graphical notation, increased
consistency and testing as a natural part leads to increased efficiency and better quality. See
Figure 12.1 for a graphical view of the benefits of using a model based software development
tool according to Combitech systems.
71 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 72 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 12.1 – Benefits of model based software development
What i would like to criticise in this comparison is that there only exists information about the
size of the code of Node A and they are using different languages. What this comparison much
likely could tell is that object oriented programming and C++ is are superior to C and
Assembler.
72 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 73 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
12.3 Rhapsody vs Tasking/Visual Studio
Introduction
Performing a fair and careful examination of software development with Rhapsody and
traditional tools like Visual Studio would be a thesis work itself and therefore I have limit me
to only perform a comparison between the different development methods.
To get a fair comparison one has to see to all phases of a development project, from the
requirement specification to the last program version. It would take many years completely
perform this kind of comparison because many applications are upgraded and improved over
the years. The different phases analysed in this comparison are; requirement specification,
design, implementation, debugging/testing, updates and changes.
Requirement specification
The first part of a development project is to make a requirement specification. The requirement
specification is a document which aims to identify all requirements made by the customer.
Making a requirement specification in for example Word takes as much time independent of
development method. In Rhapsody you can add the requirements to the project, this will of
course take some extra time but one solution would be to make the requirement specification in
Rhapsody. The requirement specification can be printed out from Rhapsody.
Many software developers have worked in projects where the requirement specification were
changed in the middle of the project and knows how much extra work it takes to change the
design and implementation. A benefit with a code generation program like Rhapsody is that
one easily can make changes in the requirements and apply these changes to the design, after
that Rhapsody will generate new code based on the new design.
Design
At traditional software development the design is created by using UML tools like Telelogic
TAU. How long time it takes to complete the design depends on the application and on the
experience and knowledge of the project members. There is one big different between
traditional design development and by using a model based tool like Rhapsody. In a Rhapsody
project the design is a part of the complete solution whiles it in for example Visual Studio only
is a blueprint used by the programmer. A code generation program like Rhapsody starts from
the design and generates code based on it. At traditional software development the design and
the implementation are separated and the design doesn’t need to as detailed as the design of a
code generation program. The conclusion is that it takes more time to make a design for
Rhapsody than for Visual Studio or Tasking, however if the software developer can spend
some time at this point he or she has everything to win in the implementation phase.
73 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 74 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Implementation
If the software developer has spent much time on the design he or she has a lot to win during
the implementation phase. At model based software development like traditional you have to
write code. At traditional software development the programmer must write most parts of the
code himself and the programmer must guarantee that the program is free of bugs and can be
updated in the future. At model based software development the programmer must of course
write some code of him/her own but most parts are already made in the design phase.
In a tool like Rhapsody you can at the design phase specify all classes, functions and variables
and their relations. The behaviour of a class can be specified by using a state chart diagram.
What manually needs to be implemented are the implementation of the different states and
functions.
At traditional programming it often happens that flaws in the design are discovered after lots of
code lines have been written and to update the design and rewrite the code may considerably
delay projects. In Rhapsody the design is a part of the complete solution and performing a
change in a model based environment is much easier, after that new code can be generated
quick and painless.
Debugging/Testing
All the tools (Rhapsody, tasking and Visual Studio) in this examination support debugging
where the user is allowed to set break points in the code to read status and step through the
code line by line. Rhapsody does also provide animation of state chart diagrams and active
generation of activity diagrams. By using the animation tool the developer may step through
the design state by state and thus check that the design works as planed. As a developer you
have much better view of the application and how it is executing than compared to a traditional
step-by-step debugging.
Active generation of activity diagrams means that Rhapsody during the execution/debugging
creates an activity diagram that corresponds to the executed behaviour. These tools are very
useful when one wants to verify his/her design. Besides if the developer locates an error that
needs to be fixed, for example a function which interface is wrong, then it’s often enough to
correct this once in the design and the remaining code will be updated according to this change.
At traditional programming the developer must locate each place in the code that uses this
incorrect function and perform the change manually.
Updates/Changes
The real benefits of using a model based development tool like Rhapsody appears when
performing changes and updates of the code. Experiences from traditional development shows
that applications that through the years are being updated a lot tend to become very complex
and badly constructed. The implementation of these changes does also take a lot of time and in
many cases where a change should require a reconstruction of the entire design the developer is
just making some kind of special workaround since rewriting the entire source code is
unthinkable. With a MBSD-tool the developer has much better view over the design and since
74 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 75 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
the code is being generated a reconstruction of the design is never a problem. The generated
code will have better consistency because all code is remade b every new generation.
Own experiences
During this thesis work I developed an application that uses the drivers of the Crossfire MX1
and that works in a simulated environment and against target. More details about this
application can be read about in the chapter The Demonstrator.
Early in this thesis work I started the development of the demonstrator so I as quick as possible
could test the drivers in a simulated environment with CC-systems simulation technology
CCSimTech. Since the drivers where written for Visual Studio and Tasking there were these
two environments the demonstrator was constructed in, Visual Studio for simulation and
Tasking for target. The source code was written in Visual Studio and the programming
language was C/C++. The time spent developing the demonstrator in Visual Studio can be
approximated to one man week, updates and improvements included.
After succeeded to construct a working demonstrator in Visual Studio I only needed to copy
the source code into a new Tasking project and Rhapsody project. The problems to fix in these
environments were some compiling and linking settings and some problems with the IDF
framework.
Earlier I had only experiences of working with Visual Studio and none of using Tasking or
Rhapsody and this caused the development of the demonstrator in these environments to take
much longer time than for Visual Studio even since all the code already was written in Visual
Studio. After I’ve learned these tools and know all the settings needed for the CrossFire
module I can say that the development in Rhapsody smooth as with Visual Studio or Tasking.
With small projects like this the benefits gained of working with Rhapsody are small and added
can be the time it takes for a developer to learn how to use Rhapsody.
75 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 76 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
13 FLASH LOADING OF CROSSFIRE MX1
The CrossFire MX1 contains an Infineon C167 CPU and twoAM29400BB flash memories. It
is to these memories the software shall be loaded to. Flash loading of the CrossFire is made
through the same connector as for power supply but with a different cable that is connected to
the serial port on the computer. In this thesis I have created a combined flash loading and
power supply cable with a switch that makes me switch functionality. See appendix
Kablage.ppt for a detailed view of how the cables are constructed.
The completed Rhapsody project must be compiled with a compiler intended for the C167
CPU. In this thesis work I have been using TASKING 8.2 from the company Althium Limited.
The result is two generated files with the suffix abs and hex. What files that should be
generated from the project can be specified in the compiler, however it is only the hex file that
works with the CrossFire MX1. By using the built-in flash loading function in Tasking or by
using other flash loading applications like Hitex Bootloader, Boot Strap Loader of FLASHit
one can specify all the necessary settings, select hex file and start the flash loading procedure.
Hitex Bootloader is not to prefer because it is much slower than the other flash loading tools.
The difference in speed depends on the flash loading procedure. The flash loading function of
Tasking, Boot Strap Loader and FLASHit uses a monitor program that is downloaded to the
memory of the CrossFire. This procedure requires enough memory to work. Hitex Bootloader
is transferring the data bit by bit, this method is very slowly and a file of about 100k takes 20
minutes to be loaded while the other programs can load the same file in just 20 seconds.
A problem that took lot of time and that couldn’t be solved was that Tasking couldn’t erase the
flash memory of the CrossFire. The erase of the flash memory had to be performed separate by
the program FLASHit, which by the way was the only application with a separate erasing
function. See Figure 13.1.
Figure 13.1 – Erasing by using FLASHit
76 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 77 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
Figure 13.2 – Flash loading with Tasking
I have in this thesis work been using CrossView which is the flash loading function of Tasking
8.5 (see Figure 13.2) because it can be called directly from Rhapsody. Also FLASHit can be
called from Rhapsody but since I didn’t have a full license it I had to use Tasking. A big
problem with CrossView was that it couldn’t erase the flash memory which is required before
each flash loading. The reason for why a flash memory must be erased before every new
loading is that during the writing to the memory only zeroes can be written. During the erase
procedure all the bits are set to one. Because of this problem it is to recommend using Boot
Strap Loader but then the file needs to be loaded manually. In the free demo version of
FLASHit you are allowed to erase the memory but not load files of a size larger than 4k.
To succeed with the flash loading with Tasking proper settings must be made so that
CrossView knows the configuration of the hardware. See appendix (Integrering av drivare i
Rhapsody.doc) for further details of the settings required. Among other settings a configuration
file that looks like Figure 13.3 is needed.
77 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 78 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
The configuration file I’ve been using looks like Figure 13.3 below:
title:
cpu_type:
bslack:
boot:
monitor:
register_file:
einit:
init:
debug_instrument_module:
RAM Monitor C167 (lillaIO settings)
167
0xD5, 0xC5, 0xA5
b167nrb.sre
m167r.sre
reg167cr.dat
$syscon = 0x0114;
$syscon = 0x0114, $addrsel4 = 0x3000,
$addrsel2 = 0x0007, $buscon2 = 0xC4Af, $buscon4 = 0xc40d;
dieva166
flash_monitor:
f167.sre
flash_direct_access:
FALSE
flash_workspace:
0x4000
flash_vendor0:
flash_chip0:
flash_chip_size0:
flash_width0:
flash_chips0:
flash_device_num:
flash_base_address0:
flash_base_address1:
AMD
AM29F040B
0x80000
8
2
1
0x0
0x0
flash_mirror_address:
flash_mirror_address1:
0x100000
0x100000
flash_mirror_device:
0
flash_unused_address_lines0:
0
reserve:
0x200-0xFFF,0xFCC0-0xFCDF,0xFD00-0xFD4B
Figure 13.3 – Configuration file for Flash loading with Tasking 8.5
The configuration file is used to inform CrossView about the current hardware setup. In Figure
13.3 settings for CPU, chip, size of memory etc. is specified. Also other information regarding
the communication and what monitor applications that should be used are specified in the file.
To be able to call CrossView or FLASHit from Rhapsody a bat file must be created. The bat
file must contain the commands supported by either Tasking or FLASHit. When a bat file with
the proper commands is created you can tell Rhapsody that every time Run is selected
Rhapsody should execute the bat file. See appendix (Integrering av drivare i Rhapsody.doc)
for more details.
78 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 79 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
After executing the bat file, CrossView will open, see Figure 13.4. The CrossFire MX1 module
will need to be connected and turned on in flash loading mode otherwise CrossView will not
be able to find the module.
Figure 13.4 - CrossView
From this point one only has to select File->Download Application, brows the right hex file
and check the box Enable flash and make sure the box Verify Download not is checked, see
Figure 13.5. After that just press Load and the downloading procedure is over in less than 30
seconds.
Figure 13.5 - CrossView, Download Application
79 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 80 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
13.1 Settings in Rhapsody’s property file
With the correct settings in Rhapsody’s property file you can make Rhapsody to automatically
call the flash loading function of Tasking and automatically load the generated hex file
(according to requirement Rw3). I will in this section present what settings that need to be
changed and what they do.
First of all Rhapsody must generate three files needed for flash loading. The first file is the
configuration file (Figure 13.3) that contains all necessary information about the hardware. The
second file is a commando file that tells CrossView what to do (specifies the hex file and starts
the flash loading). The third file is the bat-file that calls CrossView and sends the correct
parameters.
The first thing to do is to create a new property in the property file that contains the contents of
the configuration file. See Figure 13.6.
Property FlashFileContent MultiLine "
@echo title: CrossFire MX1B Settings>> FlashConfig.cfg
@echo cpu_type: 167>> FlashConfig.cfg
@echo bslack: 0x000000C5>> FlashConfig.cfg
@echo boot: b167nrb.sre>> FlashConfig.cfg
@echo monitor: m167r.sre>> FlashConfig.cfg
@echo register_file: reg167cr.dat>> FlashConfig.cfg
@echo einit: $$syscon = 0x0114;>> FlashConfig.cfg
@echo init: $$syscon = 0x0114, $$addrsel4 = 0x3000, $$addrsel2 = 0x0007, $$buscon2 =
0xC4Af, $$buscon4 = 0xc40d;>> FlashConfig.cfg
@echo debug_instrument_module: dieva166>> FlashConfig.cfg
@echo flash_monitor: f167.sre>> FlashConfig.cfg
@echo flash_direct_access: FALSE>> FlashConfig.cfg
@echo flash_workspace: 0x4000>> FlashConfig.cfg
@echo flash_vendor0: AMD>> FlashConfig.cfg
@echo flash_chip0: AM29F040B>> FlashConfig.cfg
@echo flash_chip_size0: 0x80000>> FlashConfig.cfg
@echo flash_width0: 08>> FlashConfig.cfg
@echo flash_chips0: 02>> FlashConfig.cfg
@echo flash_device_num: 01>> FlashConfig.cfg
@echo flash_base_address0: 0x0>> FlashConfig.cfg
@echo flash_base_address1: 0x0>> FlashConfig.cfg
@echo flash_mirror_address: 0x100000>> FlashConfig.cfg
@echo flash_mirror_address1: 0x100000>> FlashConfig.cfg
@echo flash_mirror_device: 00>> FlashConfig.cfg
@echo flash_unused_address_lines0: 00>> FlashConfig.cfg
@echo reserve: 0x200-0xFFF,0xFCC0-0xFCDF,0xFD00-0xFD4B>> FlashConfig.cfg
"
Figure 13.6 – Generation of Configuration File.
The commando: @echo [text]>>[Filenamen] writes the [text] in the file [Filename]
80 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 81 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
The following lines generate the abs and hex files:
$(TARGET_NAME).abs: $(TARGET_NAME).out
@echo Converting $*.out to $*.abs in IEEE-695 format
$(C166)\\ieee166.exe $*.out $*.abs
@echo Converting $*.out to $*.hex in Intel format
$(C166)\\ihex166.exe $*.out $*.hex -i32 -l32 -O -P -r
Right after these lines should the following code be placed, see Figure 13.7
@echo Creating FlashConfig.cfg
@if exist FlashConfig.cfg $(RM) FlashConfig.cfg
$(FlashFileContent)
@echo Creating CrossViewCommands.cmd
@if exist CrossViewCommands.cmd $(RM) CrossViewCommands.cmd
@echo N $(TARGET_NAME).abs>> CrossViewCommands.cmd
@echo dn $(TARGET_NAME).hex>> CrossViewCommands.cmd
@echo q y>> CrossViewCommands.cmd
@echo Creating LoadFlash.bat
@if exist LoadFlash.bat $(RM) LoadFlash.bat
@echo @echo Loading CrossView...>>LoadFlash.bat
@echo @echo off>>LoadFlash.bat
@echo $(C166)\\xfw166.exe -D rs232,COM1,57600 -tcfg FlashConfig.cfg --single_instance -load_application_download=false --load_application_verify=false --enable_flash=true -load_application_use_map_file=false --load_application_signal=false --load_application_program_reset=true -load_application_target_reset=true --load_application_goto_main=false -load_application_break_on_exit=false --load_application_c++_nd=false -p CrossViewCommands.cmd>>
LoadFlash.bat
Figure 13.7 – Code for generation of Config, Command and Bat-file
The three lines on top of Figure 13.7 are checking if the configurations file already exists and if
it does removes it. After that a new file with the content of the property FlashFileContent is
created.
The next five lines are creating the command file where the dn command starts the flash
loading procedure. The q y commands mean that CrossView should terminate without saving
any settings.
The remaining lines are creating the bat-file with the required settings.
The last thing to do is to tell Rhapsody that every time Run is selected the bat-file should be
executed. This is done by adding the name and path of the bat-file to the property
InvokeExecutable. See the following example; Property InvokeExecutable String
"LoadFlash.bat"
81 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 82 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
14 DISCUSSION AND CONCLUSION
14.1 General about MBSE
Model based software engineering (MBSE) will in time become more popular and for every
year more and more companies realizes the advantages of this new development method.
Problems of today are that there does not exist many projects where the advantages of MBSE
are shown and many of the MBSE-tools that exists on the market today are very expensive and
it take lot of time to learn how develop application with these tools. These problems are the
reason to why many companies of today are sceptical about changing to this new development
method.
14.2 The Thesis work
The integration of the CrossFire drivers in the Rhapsody project took more time than expected
and some problems that occurred during the integration led to that the different solution
propositions had to be redesigned. The main reason to why it took so long time was because
the Rhapsody environment and the drivers were completely unknown to me. However with this
thesis work I have proved that the driver s of the CrossFire MX1 can be integrated in a good
and user friendly way. The usage of the drivers in a Rhapsody project can now be done very
easily and since the code automatically generates different solutions can fast and easy be
developed and compared. The only problem I didn’t manage to solve during this thesis work
was the erasing of the flash memory with CrossView. However there are other flash loading
programs that can be used like FLASHit which also can be called from within Rhapsody.
The final solution of this thesis work is just one possible solution that CC-Systems can analyse
and continue work with. Hopefully they can come up with a standard over how the drivers of
their modules should be designed in Rhapsody. If CC-Systems can come up with a standard of
the drivers and release a user manual that in a user friendly way describes how the usages of
the driver works, then I believe there is a great potential in using Rhapsody in future projects.
14.3 Conclusion
The purpose with this thesis work was (among others) to make a conclusion about if the
customers of CC-Systems in the future should be able to use Rhapsody to program their own
IO-modules. The conclusion I can make is that the customers much likely can use Rhapsody to
program their own modules. The problems of today is in front of all the high cost per license
(150000:-) and the time it takes for a developer to learn how to use Rhapsody in a correct way.
One solution could be that CC-Systems allows their customers to use the company’s own
license and that CC-Systems also offer courses and thereby demonstrating the benefits of using
Rhapsody.
82 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 83 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
15 GLOSSARY
BusTool
Application for monitoring of CAN and LIN networks.
C167
The CPU of the CrossFire MX1b.
CAN
Controller Area Network.
CANOpen
Protocol based on CAN.
CC Pilot
On-board computer produced by av CC-systems.
CCS
CC-Systems, stands for Cross Country Systems.
CCSimTech
CC-Systems simulation tools.
CrossFire
The name of CC-Systems small IO module.
CrossView
An application for debugging and flash loading, is a part of Tasking
CPU
Central Processing Unit.
ECU
Engine Control Unit
EEPROM
Electrically Erasable Programmable Read-Only Memory.
EMC
ElectroMagnetic Compatibility
FLASH
Memory type in CrossFire MX1b.
HAL
Hardware Abstraction Layer.
IDF
Interrupt Driven Framework.
IO
Input Output.
IOTool
A tool in CCSimTech for monitoring of IO.
ISO
International Organization for Standardization
MBSE
Model Based Software Engineering.
OMG
Object Management Group
83 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 84 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
OS
Operating System.
OSI model
Open Systems Interconnection Basic Reference Model
OXF
A collection of classes and functions that is used by Rhapsody to
implement the different UML diagrams.
PLC
Programmable Logic Controller
Rhapsody
A code generation tool that uses UML and is developed by the
company I-Logix.
RTOS
Real Time Operating System
Target
The target in this thesis is the CrossFire MX1 module.
TASKING
Compiler intended for the C166 family of CPUs.
UML
Unified Modelling Language.
84 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 85 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
16 REFERENCES
LITERATURE
Related work
[1]
Utvärdering och testning av Rhapsody
(2001, 10p C-level, Mälardalen University, Jorge Råström)
http://www.idt.mdh.se/utbildning/exjobb/files/TR0111.PDF
[2]
Driftsättning av ett distribuerat styrsystem på hårdvara
(2001, 10p C-level, Mälardalen University, Helene Söderbergh)
http://www.idt.mdh.se/utbildning/exjobb/files/TR0130.pdf
[3]
Utredning av styrsystem på modern brandbil
(2004, 10p C-level, Mälardalen University, Malin Jansson & Per Lundkvist)
http://www.idt.mdh.se/utbildning/exjobb/files/TR0344.pdf
CC-Systems
[4]
Homepage of CC System, 2006-11-05
http://www.cc-systems.com/
CrossFire MX1b
[5]
CrossFire MX1b product description, 2006-11-06
http://www.cc-systems.com/downloads/C201-503-EN-CrossFireMX1.pdf
[6]
CrossFire IP67 I/O module and controller family, 2007-11-10
http://www.can-cia.org/products/pg2004/html/index-539.htm
[7]
CrossFireMX1b User manual,
CrossFireMX1b - User Manual RevC.1 20061030.pdf
85 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 86 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
CCSimTech
[8]
Product Description CCSimTech, 2007-04-20
http://www.cc-systems.com/downloads/C205-501-EN-CCSimTech.pdf
[9]
CCSimTech Programmers Guide,
SimTech Programmers Guide.pdf
[10]
CAN in Automation – CCSimTech, 2007-04-20
http://www.canopen.org/products/pg2005/html/index-257.htm
Tasking
[11]
Tasking Homepage, 2007-04-20
http://www.tasking.com/
Rhapsody
[12]
Rhapsody Homepage, 2007-04-20
http://www.ilogix.com/
[13]
Rhapsody GettingStarted,
Rhapsody GettingStarted.pdf
[14]
Rhapsody Tutorial 1
Rhapsody tutorial 1.pdf
[15]
Rhapsody Tutorial 2
Rhapsody tutorial 2.pdf
[16]
RhapsodyBrochure, 2007-04-20
http://www.ilogix.com/uploadedFiles/RhapsodyBrochure.pdf
UML
[17]
Wikipedia, 2006-11-06,
http://en.wikipedia.org/wiki/Unified_Modeling_Language
[18]
Wikipedia, 2006-11-06,
http://sv.wikipedia.org/wiki/UML
[19]
UML.org, 2006-11-07,
http://www.uml.org/
86 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 87 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
OMG
[20]
Wikipedia, 2006-11-06
http://en.wikipedia.org/wiki/Object_Management_Group
[21]
OMG.org, 2006-11-10,
http://www.omg.org/
OSI-model
[22]
Wikipedia, 2006-11-17
http://en.wikipedia.org/wiki/OSI_model
[23]
PCSupport Advisor, OSI 7 Layer Model Tutorial, 2007-04-19
http://www.pcsupportadvisor.com/OSI_7_layer_model_page1.htm
[24]
OSI Model Layers, 2007-04-19
http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html
CAN
[25]
CIA.org, 2006-11-07
http://www.can-cia.org/can/protocol/history/history.html
[26]
Wikipedia, 2006-11-07
http://en.wikipedia.org/wiki/Controller_Area_Network
[27]
Bosch, 2006-11-22
http://www.semiconductors.bosch.de/en/20/can/1-about.asp
[28]
CAN Applications, 2007-04-11
http://www.can-cia.org/applications/
Comparison Rhapsody vs. Traditional
[29]
Erfarenheter från projekt utvecklat modellbaserat och traditionellt, 2007-03-29
http://www.nohau.se/images/pdf/Slot2-Gbg-2007-03-29-Ulf-Arlig.pdf
[30]
COMBITECH, How To Save Money Using MBSE?, 2007-04-27
http://www.nohau.se/images/nec/A1-Bengt-Rydh-NEC_2006_1.0.pdf
87 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 88 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
ILLUSTRATIONS
UML-Diagram
[Figure 7.1] Class diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_classdiagram.html
[Figure 7.2] Component diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_componentdiagram.html
[Figure 7.3] Composite structure diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_compositediagram.html
[Figure 7.4] Deployment diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_deploymentdiagram.html
[Figure 7.5] Object diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_objectdiagram.html
[Figure 7.6] Package diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_packagediagram.html
[Figure 7.7] Activity diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_activitydiagram.html
[Figure 7.8] State machine diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html
[Figure 7.9] User case diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_usecasediagram.html
88 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 89 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
[Figure 7.10] Communication diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_communicationdiagram.html
[Figure 7.11] Interaction overview diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_interactionoverviewdiagram.html
[Figure 7.12] Sequence diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_sequencediagram.html
[Figure 7.13] Time diagram, 2007-04-20
http://sparxsystems.com.au/resources/uml2_tutorial/uml2_timingdiagram.html
CCSimTech
[Figure 7.19] CCSimTech Tools
http://www.canopen.org/products/pg2005/html/index-257.htm
CrossFireMX1
[Figure 8.1] CrossFire MX1b User Manual
CrossFireMX1b - User Manual RevC.1 20061030.pdf
89 (90)
Rhapsody on microcontrollers
Thesis worker
Doc Nr
Claes Paulsson
Page 90 of 90
Sec class
Supervisors
Datum
Rev
Filename
Johan Fredriksson, Jonas Ehlin
08/03/2016
7
106764898
All appendixes are in Swedish!!
APPENDIX A
See separate document: ”Hur man använder sig av drivarna.doc”
APPENDIX B
See separate document: “Integrering av drivare i Rhapsody.doc”
APPENDIX C
See separate document: “IO Portar.doc”
APPENDIX D
See separate document: “Kablage.ppt”
APPENDIX E
See separate document: “Kopplingsschema för Testbox.ppt”
90 (90)