Upload
keshav-rao
View
217
Download
0
Embed Size (px)
Citation preview
8/3/2019 Walter Phillips Thesis
1/126
i
UNIVERSITY of CALIFORNIA, SAN DIEGO
A modular architecture for rapid development
of model-based real-time systems.
A thesis submitted in partial satisfaction of the
requirements for the degree Master of Science
in
Computer Science
by
Walter Phillips
Committee in charge:
Professor Ingolf Krueger, Chair
Professor Geoffrey M. VoelkerProfessor Stefan Savage
2006
8/3/2019 Walter Phillips Thesis
2/126
ii
8/3/2019 Walter Phillips Thesis
3/126
iii
The thesis of Walter Phillips is approved
_____________________________________________
_____________________________________________
_____________________________________________
Chair
Geoffrey M. Voelker
Stefan SavageIngolf Krueger, Chair
University of California, San Diego
2006
8/3/2019 Walter Phillips Thesis
4/126
iv
Dedication
Harry J. Phillips1932-2004
8/3/2019 Walter Phillips Thesis
5/126
v
Table of Contents
Signature Page...................................................................................................................iiiDedication..........................................................................................................................iv
Table of Contents ...............................................................................................................v
List of Figures...................................................................................................................viiAbstract of the Thesis .....................................................................................................viii
1. Introduction ....................................................................................................................1
1.1. Inadequacies In The Traditional Software Development Process ........................... 21.2. An Improved Approach to Software Development ................................................. 41.3. Applications in the Automotive Domain ................................................................. 8
1.3.1. Case Study The Automotive Central Locking System................................ 111.4. Model-based Development .................................................................................... 12
1.5. Tool-Chain Overview: ........................................................................................... 141.6. Related Work ......................................................................................................... 16
1.7. Chapter Overview.................................................................................................. 172. Model, Code Generation, and Runtime Architecture ..............................................192.1. Goals ...................................................................................................................... 21
2.1.1. Minimize complexity...................................................................................... 212.1.2. Straightforward Code Generation................................................................... 222.1.3. Code Modularization ...................................................................................... 22
2.2. Code Generator Input............................................................................................. 232.2.1. Templates........................................................................................................ 23
2.2.2. XML Model Specification.............................................................................. 242.3. Runtime System Foundation.................................................................................. 26
2.3.1. Runtime Framework ....................................................................................... 27
2.4. Code Generator Output .......................................................................................... 282.4.1. Interface Definition Language (IDL) File....................................................... 28
2.4.2. Common Library............................................................................................. 292.4.3. Runtime Components...................................................................................... 31
2.4.3.1. Environment............................................................................................. 31
2.4.3.2. Execution Components ............................................................................ 322.4.3.3. Monitor..................................................................................................... 32
3. Design Flow, Tools, and Artifacts ...............................................................................343.1. Modeling Tool........................................................................................................ 34
3.1.1. Common Model Specification........................................................................ 35
3.1.2. Model Simulation & Validation...................................................................... 363.1.3. Model Execution............................................................................................. 36
3.2. Runtime System Architecture ................................................................................ 373.2.1. CORBA Primer............................................................................................... 383.2.2. Runtime System Execution Framework ...................................................... 40
4. Running Example.........................................................................................................424.1. Central Locking System Review ........................................................................ 42
4.2. Development Process Overview From Abstract Model to Executable .............. 43
8/3/2019 Walter Phillips Thesis
6/126
vi
4.3. Model and Code Examples .................................................................................... 435. Implementation Platform, Runtime System, and Code Generator......................52
5.1. Code Generator Evolution..................................................................................... 535.2. CORBA Runtime Communication Middleware................................................. 53
5.2.1. CORBAs IDL Compiler ................................................................................ 54
5.2.2. CORBAs Naming Service:............................................................................ 565.2.3. CORBAs Real-Time Event Service (RTES):................................................ 58
5.3. A Modular Runtime Platform Implementation Details ...................................... 615.3.1. Framework ...................................................................................................... 62
5.3.2. CommonLibrary.............................................................................................. 675.3.3. Execution Components ................................................................................... 68
5.3.3.1. Model Components (Component[Name]) ............................................... 70
5.3.3.2. ComponentEnvironment .......................................................................... 735.3.3.3. ComponentMonitor:................................................................................. 74
5.4. Code Generation Approach.................................................................................... 775.5. Code Generator Architecture ................................................................................. 79
5.5.1. Initial Code Generator Comparison Architecture ........................................ 825.5.2. Initial Code Generator Target Runtime Environment ................................. 835.5.3. Current Code Generator Target Runtime Environment (Overview) ........... 85
6. Porting to Other Runtime Environments ..................................................................876.1. Porting Concepts Basic Services ........................................................................ 896.2. Basic Services Comparison.................................................................................... 91
6.3. Web Service Integration......................................................................................... 927. Design analysis .............................................................................................................97
7.1. Design Motivation Analysis .................................................................................. 977.2. Execution Model Limitations ................................................................................ 987.3. CORBA Limitations .............................................................................................. 98
7.4. Code Generator and Runtime System Redesign Analysis................................... 1037.5. Runtime System Design Assessment ................................................................... 106
8. Future work................................................................................................................1109. Conclusion ..................................................................................................................112Bibliography ...................................................................................................................114
8/3/2019 Walter Phillips Thesis
7/126
vii
List of FiguresFigure 1-1 Waterfall Approach........................................................................................... 3
Figure 1-2 Cyclic Development .......................................................................................... 5Figure 1-3 Concentric Development Cycle ........................................................................ 7
Figure 1-4 Automotive Networks ....................................................................................... 9
Figure 1-5 Central Locking System.................................................................................. 11Figure 1-6 Code Generation Feedback Cycle................................................................ 13
Figure 1-7 Tool-Chain Overview...................................................................................... 14Figure 1-8 Tool-Chain Entities ......................................................................................... 16
Figure 2-1 Code Generator - Overview ............................................................................ 20Figure 2-2 Example XML Specification........................................................................... 25Figure 2-3 XML Component Node Specification ............................................................ 26
Figure 2-4 CommonLibrary Files ..................................................................................... 30Figure 2-5 CORBA Component Inheritance .................................................................... 31
Figure 3-1 Code Generator Flow - Overview ................................................................... 34Figure 3-2 Component View ............................................................................................ 37
Figure 3-3 CORBA ........................................................................................................... 39Figure 4-1 Central Locking System Review..................................................................... 42Figure 4-2 Example Component State Machines ............................................................. 44
Figure 4-3 Tick Method Code........................................................................................... 45Figure 4-4 Template Example........................................................................................... 47Figure 4-5 Component Startup Code ................................................................................ 48
Figure 4-6 Receive Event Code ........................................................................................ 49Figure 4-7 Send Event Code ............................................................................................. 50
Figure 5-1 Example IDL File............................................................................................ 55Figure 5-2 Code Generation Flow - Detailed ................................................................... 56Figure 5-3 Component Dependencies............................................................................... 61
Figure 5-4 Framework Class Diagram.............................................................................. 63Figure 5-5 Send Event - Overview ................................................................................... 64
Figure 5-6 Framework Hierarchy Multiple Platforms ................................................... 66Figure 5-7 Example Component State Transition............................................................ 69Figure 5-8 Component Startup Message Sequence ....................................................... 72
Figure 5-9 Receive Event Message Sequence ............................................................... 73Figure 5-10 Send Event Message Sequence .................................................................. 73
Figure 5-11 Interoperation Between C++ and C#............................................................. 76Figure 5-12 Runtime Component Hierarchy General.................................................... 86Figure 6-1 Framework Porting Dependencies .................................................................. 87
Figure 6-2 Porting Services and Libraries ..................................................................... 90Figure 6-3 Platform Specific Services Comparison.......................................................... 92
Figure 6-4 Web Service Based User Interface.................................................................. 93Figure 6-5 Web Service Code........................................................................................... 94Figure 6-6 Example WSDL File ....................................................................................... 96
Figure 7-1 CORBA Limitation Fully Interconnected Components............................. 101Figure 7-2 CORBA Limitation Maximum Number of Components ........................... 102
8/3/2019 Walter Phillips Thesis
8/126
viii
ABSTRACT OF THE THESIS
A modular architecture for rapid development ofmodel-based real-time systems.
by
Walter Phillips
Master of Science in Computer Science
University of California, San Diego, 2006
Professor Ingolf Krueger, Chair
Increasing complexity in design and implementation of distributed real-time
systems motivates a reassessment of the tools and methodologies used to develop these
software systems. We approach the problem by applying a systematic process of model-
based development, which allows the developer to apply systematic and rigorous testing
on an abstract system model. Although a wide range of modeling tools exist, they lack
combined support for real-time properties and robust code generation tools. We address
both concerns by developing a runtime Framework that supports real-time property
specification and simplifies code generation through modularization and isolation of
dynamic code.
Support for real-time property specification is accomplished through the use of
the real-time middleware platform, CORBA. This allows us to focus on using the API for
real-time functionality, rather than how to implement that functionality. Our work
automates the model-to-executable translation process providing two benefits. First, code
generation reduces coding and interpretation errors, allowing the developer to focus on
the intricacies of the target platform rather than the general execution structure of the
system. Secondly, automated translation of an abstract model into executable code allows
us to take advantage of cyclic development. A wide range of systematic tests can be
8/3/2019 Walter Phillips Thesis
9/126
ix
applied on different forms of the same model. Although validation and verification can be
performed on the abstract model, some flaws can only be uncovered under real world
conditions. A concentric development cycle, as we propose, ultimately reduces
production costs by eliminating many of the human induced flaws in the resulting
product.
8/3/2019 Walter Phillips Thesis
10/126
1
1. Introduction
Distributed real- time embedded systems, such as those found in automotive
systems, are challenging to develop. Real-time systems are typically safety critical
systems and as such, must be subjected to rigorous validation, verification, and testingbefore they can be implemented in production systems. Complex real-time systems such
as these are difficult enough to develop; add strict time to market constraints and frequent
modifications (in terms of both hardware and software requirements) and these systems
become even more difficult to develop. Traditional software development techniques as
applied to business software, for example, do not adequately address the difficulties that
may arise from real-time safety critical systems. In order to address both safety and time-
to-market constraints, we propose a methodology for rapid development through
modeling. Modeling allows for a more rigorous and methodical application of validation,
verification, and testing, than can be attained from production executable code alone.
The traditional approach to software development includes steps for validation,
verification, and testing, but they are often applied in a liner fashion and in a more
informal process. In other words, changes applied in a traditional software development
cycle may not be subjected to the rigorous validation process that was applied on initial
development. Writing code, performing extensive testing, and implementing
modifications based on testing can be a time intensive and very error-prone process.
Testing, for example, can be performed very methodically, but as the complexity of the
system increases, the complexity and time spent on testing does not increase
appropriately in typical software development practices. This is due in part to the amount
of time spent manually implementing changes directly in source code. Making small
changes in code requires lengthy testing. Because the availability of testing tools for the
specific language and project under development may be limited, a great deal of time
must be invested in developing custom testing suites or, the developer may simply choose
to use old fashion approaches of trial and error for testing.
1
8/3/2019 Walter Phillips Thesis
11/126
2
A better approach to testing is to make use of existing simulation tools that
provide a rigorous testing methodology. Production systems can be developed to mimic
the testing and simulation environment. Although this constrains the developer in
building the system, it provides a convenient and standardized testing environment. The
simulation tools execution environment is likely to be well structured as compared to
freeform custom execution environment. Because of this well-structured execution
similar testing methodologies can be extended into the real system, beyond the simulation
environment. This methodology is made possible by abstracting the system into a model
that can be systematically tested. This is referred to as the model driven development
approach (MDA for short).
1.1. Inadequacies In The Traditional Software Development Process
The traditional approach to software development is error prone because of two
primary reasons. First, the use of developer resources is inefficient at best and secondly,
human interactions can introduce errors. Writing code by hand introduces a number of
potential problems. Simple syntactical errors, although caught by compilers, can lead to
inefficient use of time and resources, especially if the project is large and slow to
compile. Syntactical errors arise for a number of reasons, most of which stem from
sloppy or poor coding practices. Although syntax errors are serious, they generally pose a
minimal concern to the overall stability of a given system, as those errors must be
repaired before the system can be compiled and deployed. Of far greater concern is the
potential for human induced logic errors. Any novice or professional developer will
agree, logic errors are much harder to find and can lead to devastating consequences. A
great deal of time and resources are devoted to testing and debugging in order to reduce
or eliminate logic errors. Reducing the amount of handwritten code can, in turn, reduce
the time spent debugging [GriffithsHedrick].
Our goal is to reduce the amount of manual coding in order to reduce the
frequency of syntactical and logical coding errors. Logic errors can arise from incorrect
translation or implementation of an abstract specification. An abstract specification,
whether it be a formal model, or an informal collection of requirements, can define tasks
8/3/2019 Walter Phillips Thesis
12/126
3
as simple as setting a variable, or as complex as enabling an output state before a
specified deadline while communicating success or failure. Logic errors can also arise
from incorrect, incomplete, or flawed specifications. Much research has been devoted to
formalizing specification methods [Romberg02] [Rumpe02] [OMG] [UML]. Tools have
evolved out of formal specification that aid in the analysis of abstract specifications. The
Unified Modeling Language (UML) for example, has been successful as a specification
tool to enable visualization of complete systems and internal component interaction.
Beyond simple visualization of systems, tools exist to apply systematic verification and
validation of these abstract specifications. Unfortunately, the act of translating the
abstract specification into executable code is typically still a manual, and hence error-
prone, process. We integrate automated code generation to the abstract model
specification to ensure translation errors are minimized and the resulting product is as
correct as the initial specification.
System
Requirements
Capture
Model Generation
Verification andValidation
Code Generation
Code MaintenanceDocumentation
(Model Maintenance)
Figure 1-1 Waterfall Approach
Traditional software development can be visualized as a linear process,often referred to as the waterfall approach. Because of the linear top-
down sequence, errors uncovered must be remedied from that pointforward.
Model driven development has seen a great deal of success in other engineering
fields due in part to its ability to abstract complex systems into a more manageable state.
Models can then be subjected to rigorous testing, validation, and verification. The success
of the model driven approach in mechanical engineering, for example, can be attributed
8/3/2019 Walter Phillips Thesis
13/126
4
in large part to the advent of computerized machinery (CNC machines) that allow the
engineer to rapidly produce prototype parts out of an abstract model. The software
engineering field has a notion of rapid prototyping through tools that can be collectively
referred to as code generators. Code generators are often used to automate redundant
tasks such as providing skeleton code. Many C++ programming environments will
provide a skeleton code file when a new project is created. More robust code generators
consider system behaviors, in addition to system structure, to produce code directly out of
an abstract model, rather than coding entirely by hand. Unlike the simple structural C++
skeleton code generator, this behavioral model based code generator is dynamic,
constructing its output based on a robust specification. This allows the developer to focus
on more specific tasks.
Code generators tend to occupy a distinctly different space in the development
cycle of a piece of software as compared to the development cycle of a mechanical part,
for example. The development cycle of a mechanical part is deeply intertwined with the
abstract model because the part generation phase is automated and dependent on the
model specification. Circumventing the development process of a mechanical part is
incredibly difficult as the development process is well defined and tightly integrated. This
automation reduces both development and production costs. Software engineering does
not have a similar reproduction cost, as replication can be as simple as copying files.
Update and deployment costs for software development should be considered, but are
largely detached from development costs. The software development cycle, unlike that of
a mechanical engineer, tends to be more freeform allowing (or at the very least, not
forbidding) the developer to circumvent the model and implement changes directly in the
resulting source code.
1.2. An Improved Approach to Software Development
Model driven development has proven to be a very useful design approach in
many engineering fields. Computer Aided Software Engineering tools (CASE for short)
are a general class of tools that enable engineers to methodically and systematically
8/3/2019 Walter Phillips Thesis
14/126
5
develop complex systems through the use of abstract computer-based models. Robust
validation, verification, and simulation tools ensure the correctness of systems before
they are ever implemented in a tangible form. Although CASE tools have experienced
much success in other disciplines, software engineering has been reluctant to accept them
in any wide spread or unified sense. Use of CASE tools is gaining acceptance but they
are typically utilized for initial design or documentation and are not tightly integrated into
the development and code maintenance cycle as a whole. We aim to achieve a tightly
integrated development cycle through automating the specific task of translating an
abstract model specification into a practical executable system. This automated
translation is accomplished via a tool appropriately called a Code Generator, not to be
confused by the general class of tools by the same name.
Testin
g
Valid
atio
n
Code
Generation
Model
Changes
Figure 1-2 Cyclic Development
Cyclic Development refers to the way in which code is developed, tested,and changed.
Advanced CASE modeling tools have received wide spread acceptance from
much of the general engineering community. Examples include Computer Aided
Drafting, CNC machines, circuit design tools, and so on. Software based models are ideal
in that they are easy to build and easily modified. Beyond their simple prototyping utility,
analysis and simulation tools can apply validation and verification as well as systematic
testing procedures. Traditional software development can, and does, benefit from a
systematic approach as it yields improved confidence in the resulting product. The
8/3/2019 Walter Phillips Thesis
15/126
6
problem as we see it is that systematic approaches in traditional software design are
fractured and loosely integrated throughout the development cycle.
A relatively new trend in the software engineering field, called eXtreme
Programming (XP) seeks to uncover flaws through iterative development and unit testing.
This form of unit testing greatly improves the ability to catch flaws and can be applied to
both critical and non-critical system developme nt. Rather than focusing on small unit
tests, we take a more holistic approach to design and testing of entire systems. Through
the use of code generation, we enable complete systems to be tested incrementally
through rapid deployment on platforms that more closely approximate the target system
and ultimately the target system itself. This improves on the unit testing approach as it
includes system interactions. Traditional unit tests could still be applied to parts of the
resulting system and would provide additional and repeatable testing tools. These tests
must be implemented manually and specifically for the given project under development.
Our approach to model driven development utilizes a cyclic pattern of
verification, validation and modification. This general approach should be followed for
all software development practices, but is not always adhered to strictly. Individual
tools for modeling and simulation have gained some acceptance, but a unifying
development process that integrates these tools from initial design to final production and
through subsequent development has yet to gain wide spread acceptance. While we do
not aim to achieve wide spread acceptance, we do aim to explore and promote a unified
development process based on the model driven development pattern. In short, the model
is the central entity of our development process and all changes or modifications to the
system under development must be made directly in the model. Subsequently those
changes must pass through the phases of model validation and verification, simulation
and testing, and finally deployment and testing. We use the term concentric
development cycle to denote the fact that the model is the central entity and
development occurs in layered phases, each phase achieving specific goals, and each
phase further approximating the real system. Modifications are applied to the model
8/3/2019 Walter Phillips Thesis
16/126
7
directly and, by forcing those changes to undergo the full testing and validation cycle, we
methodically assure that the changes are sound.
Deployment& Testing
Simulation& Testing
Internal CodeGeneration
Executable Code
Generation
ModelModifications
ModelValidation/
Verification
Initial RequirementsCapture and ModelConstruction
Figure 1-3 Concentric Development Cycle
The concentric development cycle requires that all modifications pass
through the model. Those changes are then subjected to rigorousvalidation, verification, and testing methods. These same tests can be
applied for each minor change to the system.
The concentric development cycle, as we have defined it, has three main cycles,
namely internal verification/validation, internal simulation, and external simulation. This
notion of three cycles is by no means a limitation. In fact, it is envisioned that any
number of additional cycles would be added to test various aspects of the system under
development culminating in the final production system. A notion of parallel cycles could
be used to rapidly explore different execution platforms or communication environments.
For example it would be desirable for a production system to utilize a simple
communications environment such as TCP/UDP, CAN, or even Web Services, as
opposed to a more heavyweight middleware platform such as CORBA (CORBA is
discussed in depth in Chapter 3.2.1 below). On the other hand, advanced platforms such
as CORBA can provide many useful features. Traditionally, the costly decision of which
communications environment to use must be made upfront as all subsequent development
8/3/2019 Walter Phillips Thesis
17/126
8
follows from that decision. Our approach removes, to some degree, the strict dependence
on the underlying platform. This allows the developer to focus of the functionality of the
system first and the underlying low-level implementation second.
Platform independence, as we have defined it, is by no means automatic. It
requires limited development in the model-to-code translation tools (i.e. the Code
Generator) and extensive changes to the execution Framework. Fortunately, code
modularization minimizes the impact of the Framework changes on the Code Generator.
Still, the ability to utilize the same fundamental system model in different environments
is useful to make informed design decisions early in the development process. In
particular, the modularization of system logic into an abstract model would be useful to
industries where cost drives frequent vendor changes, and thus frequent hardware
changes. A prime example of this environment can be found in the automotive industry.
1.3. Applications in the Automotive Domain
The automotive domain is a particularly interesting application for a robust
development cycle aimed at reducing errors and expediting time to market. The
automotive industry has a mass market with deep social impacts in terms of safety and
utility. In addition, automotive software and hardware is in constant flux. Automotivesoftware requirements are constantly revised or changed to keep up with demand for
added features and system interoperation. Maintainable code is particularly important in
the automotive industry due to the use of many different hardware vendors. For example,
a given electronic control unit (ECU) hardware may change within a given production
run, but the tasks it performs are likely to only change through successive production
runs and model years. Changing hardware often creates a requirement for changing code,
which is fine if the set of tasks change. If the set of tasks is unchanged, rewriting code
can be wasteful, especially if the only reason for this rewrite is a hardware change. Code
that is maintainable, portable, and stable beyond the initial production run is of great
importance to the automotive industry.
8/3/2019 Walter Phillips Thesis
18/126
9
Abstract modeling is particularly suitable in this environment of frequent
hardware and software changes because models naturally abstract the hardware layer. An
example in the automotive domain is the system controlling the power door locking
mechanism, referred to as the Central Locking System, or CLS for short
([KrgerGuptaMathew04], [AhluwaliaKrgerMeisinger05]). This system, although
simple on the surface, interfaces with a wide range of systems and so it provides many
distinct examples of the challenges facing automotive software development. The Central
Locking System is distributed over a number of subsystems. The most interesting of
which, collision detection, adds hard real-time constraints.
Chassis Communications Bus
Safety Bus
Door Locks Dashboard
Airbags
Drivetrain Bus
Engine Control
Crash Detection
Transmission
Figure 1-4 Automotive Networks
Automotive systems are fundamentally distributed.
Figure 1-4 shows a typical automotive network. Although systems may reside on
different physical networks (or buses) they must interoperate where appropriate. For
example, during a crash, the airbags must deploy with high priority. Dotted arrows
demonstrate communication originating from the Crash Detector. Secondary to airbag
deployment, the door locks must disengage and the engine must shutdown. Some
automotive systems utilize the CAN bus and associated protocols for communication
between these distributed components. We utilize a different but loosely analogous
communications medium called CORBA.
8/3/2019 Walter Phillips Thesis
19/126
10
Production central locking systems are also faced with long-term support and
maintenance issues. The initial design may require the locking system to take inputs from
the internally mounted lock/unlock switch and the remote Key Fob (for keyless entry).
Subsequent model years may require the locking system to take additional inputs from a
cellular or satellite network, an externally mounted numeric keypad, or possibly even
biometric sensors. Simply modifying the code to accept the additional input may cause
adverse consequences in other aspects of the complete system. Model driven testing of
even a simple interface change would greatly reduce potential problems, and thus
increase confidence in the resulting product. Because typical automotive ECUs are not
field-programmable, the confidence in software validity also reflects a potential cost
savings by avoiding flaw leading to recalls or customer dissatisfaction.
Addressing code changes through subsequent versions is far more difficult than
simply modifying code directly. Uncovering effects of these changes on the rest of the
system can prove a daunting task. For example, a newly updated function may take
slightly longer to execute, thus causing a dependent sequence of events to fail. More
importantly, these logic changes can have adverse effects on safety-critical systems.
System changes must be thoroughly tested before they can be deployed. The amount of
time and resources devoted to this testing is often insufficient due to financial or political
limitations (such as deliverable deadlines). Because of these resource constraints, it is
therefore extremely desirable to utilize the available development resources efficiently in
order to maximize the confidence in the final product. Automation can provide a great
deal of help in finding and eliminating flaws. The tradeoff between development and
testing resources requires careful and efficient use of these resources in order to ship the
product with the minimum allowable general flaws and, because of the nature of
automotive systems, absolutely no safety flaws. General flaws (not safety related) can be
addressed through subsequent model years as discussed above. Our work provides a
means to test for these flaws and to address changes through different model years by
utilizing and maintaining an accurate system model throughout the lifetime of the
product.
8/3/2019 Walter Phillips Thesis
20/126
11
1.3.1. Case Study The Automotive Central Locking System
The running example we will discuss is the Central Locking System. This is an
appropriate example from the automotive domain because it is component-based,
physically distributed, and can be specified to contain real-time constraints. For this
example the Central Locking System will consist of a number of interconnected
components and subsystems. These include a Key Fob (KF), a Lock Manager (LM),
Lighting System (LS), Crash Sensor (CS), etc. The Central Locking Systems core
component is the Control unit, which interacts with the above as well as an entertainment
system through a Database (DB), Tuner, and User Interface (UI).
Figure 1-5 Central Locking System
The Central Locking System (CLS) block diagram.
Each of these components logically maps to a component in the abstract model
and consequently an executable in the runtime system. Each executable contains an
interface to the underlying runtime communications environment and the logical internal
state machine defined in the corresponding model component. As in a real central locking
system, the execution components are physically distributed. For the sake of simple
testing and deployment, our runtime executable components can be run as separate
processes on the same machine. In addition to the system components we introduce aspecial monitoring component, discussed later. The monitor is used for non-invasive
testing and control of the runtime system and is discussed in depth later.
8/3/2019 Walter Phillips Thesis
21/126
12
1.4. Model-based Development
Models of software systems are abstract and as such, look nothing like their
implementation. In contrast, models in the mechanical, electrical, or structural
engineering fields are intuitive and look very similar to their physical implementation.
The ability to visualize abstract models, and the dynamic nature of software in general,
gives the developer an aversion to the modeling techniques that have proven useful in
other disciplines. In some respects, programming is more of an art than a science.
Programmers often develop an intuition for writing code as well as a deep knowledge of
the system under development. This knowledge manifests itself in optimization and
creative approaches towards solving particular problems. No automated code generation
system can replace this creativity and detailed understanding of the systems. Still,
software design and development can benefit from modeling for the same reasons otherengineering disciplines benefit. These include increased productivity, reduced exposure
to human induced errors, cost reductions, etc. Modeling allows for the application of a
systematic and unified approach to both design and testing
Modeling techniques in general have been gaining acceptance in software
development. Still, a problem with traditional software development arises once the
system has been implemented in real code; the model and implementation are allowed to
diverge. Successive changes are often implemented in the real code, while the model is
changed to reflect those code modifications. In this respect, the model often deteriorates
into a documentation tool rather than an integral part of the future development cycle. As
such, the models utility as a testing tool diminishes.
8/3/2019 Walter Phillips Thesis
22/126
13
Figure 1-6 Code Generation Feedback Cycle
With automated code generation, feedback is applied in a more efficientmanner. Modifications experience the rigorous testing methods of the
complete tool-chain in order to discover potential flaws.
We aim to change the traditional software development cycle to be more
proactive in all stages of development. That is to say, the development cycle aims to
uncover flaws in all phases, rather than just the deployment or testing stages. This is
accomplished by altering the traditional flow of development. Rather than changing the
model to reflect changes in the system, the changes should be made to the model first.
This tight coupling of model and system means the system should always reflect the
model, and not vice versa. Changing the model, rather than the code, adds an extra step
that most programmers would find redundant. Manually changing the system to reflect
the model, or vice-versa, can introduce a number of coding and logical errors. Our goal is
to reduce the burden on the programmer by automating the task of building the system
from the model. The simplification of the system building process through automation is
likely to increase the acceptance and use of our particular tool-chain, resulting in more
efficient use of the programmer's skills. More importantly, the automation process should
reduce the number of model translation errors (logical or otherwise).
The focus of this text is to demonstrate how the automated generation of
executable code directly out of the model allows and reinforces a concentric development
cycle. Without automatic code generation, the labor cost of implementing the system out
of the model is prohibitive and likely to only take place once; that is the initial
8/3/2019 Walter Phillips Thesis
23/126
14
translation. This is, in part, why the code-base and model may diverge in a traditional
development cycle. With automation it becomes easier to change the model first, making
the concentric development cycle feasible. The model can be immediately tested within
the modeling tool using its native simulation environment. Once the model is thought to
be reasonably correct, the systems code can be generated and tested on a larger scale
using the same methodology. The generated executable code is designed to run in a
distributed environment that more closely matches a real environment, if not the actual
production environment itself. Under traditional software modeling techniques, the model
and system could diverge at this point. Our tool-chain requires that inconsistencies
uncovered in any testing phase be modified, not in the real system code, but in the model
itself.
1.5. Tool-Chain Overview:
Figure 1-7 Tool-Chain Overview
The tool-chain consists of modeling, validation/verification, and codegeneration tools. The important contribution of this work is to close theloop in the development cycle. Feedback and subsequent changes must
now be applied to the model, rather than directly in the deployment code,as a traditional development would have allowed.
The fundamental purpose of this work is to demonstrate a tool called the Code
Generator which is in integral part of a much larger tool-chain
[KrgerGuptaMathew04], [AhluwaliaKrgerMeisinger05]. In general terms, a code
generator can be as simple as text replacement or as complex as modern compilers
(including intelligent optimizations, etc.). In either case, a code generator simply
translates an abstract specification into a more detailed specification, one that can be
Feedback
8/3/2019 Walter Phillips Thesis
24/126
15
directly or indirectly executable. To accomplish this translation, the Code Generator
requires detailed knowledge of both the input specification (i.e. the model), and the
output architecture (i.e. the target run-time platform). We have chosen to use a specific
modeling tool called AutoFOCUS (or a similar tool called M2Code) and a specific
runtime platform based on the CORBA middleware ([Schmidt98], [Vinoski99]) to
implement our Code Generator. It should be noted that these tools are used in the
implementation of our Code Generator and have no fundamental constraint on the
concept of code generation in general. We demonstrate through carefully architecting a
runtime Framework that it is possible to interchange the underlying communication
infrastructure. This allows us to target other environments while utilizing the same Code
Generator.
In order to demonstrate the Code Generator, we utilize the running example of the
Central Locking System and the specific aspects of this particular system. The running
example is presented in general terms and is meant to describe the code generation
process as a whole. In short, the larger tool-chain utilizes tools in three main areas, model
specification, validation, and code generation. Modeling specification tools include
AutoFOCUS [HuberSchaetzSchmidt96] and M2Code [KrgerGuptaMathew04].
Validation tools include AutoFOCUS [LtzbeyerPretschner00] and MSCCheck
[KrgerGuptaMathew04]. Lastly, code generation tools include the Code Generator itself
[Mller03] as well as an improved runtime environment and a new monitoring
component. This work focuses on the area of code generation and its supporting target
runtime environment.
8/3/2019 Walter Phillips Thesis
25/126
16
AutoFocusAutoFocus
ConnectorConnector
XMLXML
ValidationTools
ValidationTools
Testing andrefinementTesting andrefinement
CodeCode
RTCGeneratorRTCGenerator
XMLXML
M2Code(MS Visio Plugin)
M2Code(MS Visio Plugin)
Figure 1-8 Tool-Chain Entities
Our tool-chain workflow is dynamic. The cyclic flow of development
tasks pas through the various tools. Changes are never applied directly tothe generated code.
1.6. Related Work
In the current state of the art, tool-chains facilitating the development cycle
outlined above do exist. The Rational Rose suite and the Nucleus BridgePoint suite from
Mentor Graphics [MENTORWEB] facilitate model to executable development, but they
do not provide explicit means to specify real-time properties to be enforced. They can
however be observed and tested in the traditional sense. The goal of the tool-chain under
development ([KrgerGuptaMathew04], [AhluwaliaKrgerMeisinger05]) is to provide ameans to specify real-time properties as a part of the modeling process and to have these
specifications mapped to an enforcing mechanism in the final executable. The purpose of
this work is to bridge the gap between the models notion of an execution environment to
that of a physically distributed execution environment capable of handling the real-time
property enforcement.
A great deal of research has been applied in the field of model-based
development. Our approach is similar in spirit to Executable UML. Executable UML is a
subset of the Universal Modeling Language [Rumpe02] that allows for clear generation
of code from abstract specifications. Our approach uses a more rigid execution plan that
constrains the model into a well-defined structure. From this well-defined structure it is
8/3/2019 Walter Phillips Thesis
26/126
17
possible to build an execution Framework that supports real-time properties, as those
properties can be integrated into that specification structure. Platform specific execution
frameworks can also create a natural separation of code. Code emulating the general
execution of the underlying model simulation environment can exist apart from code
belonging to the logical execution of the particular system under development. This
means the process of code generation can be localized to where it is needed. Redundant
or static code can be encapsulated to further simplify the process of code generation.
A result of modularization is that dynamically generated blocks of code can be
easily identified and transformed into a template file. Template files are standard C++
files with the addition of special tags that can be used to perform simple text replacement
or more complex code block replacement. Code templates are used extensively for
intermixing dynamic and static entities. Our inspiration for using templates derives from
certain web programming languages that use a tag based replacement scheme. Primary
inspiration for pursuing a template/tag-based approach came from languages such as PHP
[PHPWEB] and ASP [ASPWEB], but unlike these languages, we do not place interpreted
code in the template tags. Instead, tag identities and flow control constructs are kept to a
minimum. In addition to simple text replacement, special looping constructs allow
enumeration of component names or more complex code replacement over a range of
values. With respect to execution and functionality, our template language is very
different from ASP or PHP. The basic idea of placing dynamic tags in a static template
file in order to dynamically generate a statically viewable file is similar.
1.7. Chapter Overview
The remainder of this text is presented as follows; Chapter two presents an
overview of the architectural approach to code generation. The goals for the architecture
and the various tools contributing to this architecture are discussed. In addition, the
runtime tools and artifacts are presented. Chapter three expands on the tools and artifacts
presented in Chapter two. The specific tools and building blocks, from the modeling
phase to the runtime system are presented in depth. Chapter four discusses a running
8/3/2019 Walter Phillips Thesis
27/126
18
example from the automotive domain, namely the Central Locking System. Chapter five
discusses the actual implementation of the runtime system by tracing the evolution of the
code generator. The specific communications infrastructure, CORBA, is discussed in
relation to the runtime Framework. The various pieces of the current modular runtime
Framework are discussed in detail. Chapter six expands on the concept of a modular
runtime Framework by discussing how it can be ported to other environments. This
ability to port the runtime system to other platforms is a fundamental contribution of this
work. Chapter seven presents a critical analysis of the design, the model limitations, and
the tools used. Chapter eight discusses areas of future work and Chapter nine outlines
conclusions derived from this work.
8/3/2019 Walter Phillips Thesis
28/126
19
2. Model, Code Generation, and Runtime Architecture
This chapter discusses the general architecture of the code generation process
from the initial modeling phase to the resulting code generation phase, focusing primarily
on the latter. We have chosen to utilize modeling for the foundation of our codegeneration system. Generically speaking, in order to generate code, an abstract
specification must be present. For our purposes we require that this abstract specification
be rigidly defined and thoroughly tested. Modeling tools help create this abstract
specification by allowing the user to visually design the various aspects of a system to be
developed using our tool-chain. The structural and behavioral aspects of the system under
development can be modeled and thoroughly tested early in the overall development
process. Structural and behavioral models allow us to approach the code generation task
from a similar perspective. We built a generic runtime Framework to support the
structural model of components, their communications channels, and related supporting
infrastructure. The behavioral models for each component, namely their state-machine
definition, are easily integrated into the executable system because all of the necessary
support functions for initialization and message passing are already provided through the
runtime system. The behavioral (state-machine) models are translated to if-else blocks
and integrated, via code generation, into their corresponding component source code.
19
8/3/2019 Walter Phillips Thesis
29/126
20
Code Generator
XML Model
Specification
Component
C++ Files
Common
Library
C++ Files
Project
SpecificSupport Files
(IDL File)
C++
Compiler
C++Compiler
C++
Compiler
Executable
Components
CommonLibrary.dll
Framework.dll
...
Modeling
Tool
Component
Templates
Common
LibraryTemplates
Framework
C++ Files
Figure 2-1 Code Generator - Overview
The code generation process is outlined from left to right, top to bottom.
Our work focuses on the specification to executable translation and primarily on
the supporting execution runtime environment. For this discussion, we will assume the
initial modeling task has already been performed and its specification available in the
M2Code/AutoFOCUS XML specified file format. For more information on the modeling
process itself, please refer to [HuberSchaetzSchmidt96] [Mller03] and
[KrgerGuptaMathew04]. The Code Generator process utilizes a template-based
approach. In short, the template-based approach to code generation uses a generic system,
or template, to localize the code generation task to specific locations and blocks of code.
Our code generation process combines the model specification with prewrittentemplate files to produce C++ source code, which can be immediately compiled. The
overall architecture of the generated code files is modularized to separate dynamically
generated code from underlying platform dependencies. Figure 2-1 is a graphical
representation of the workflow within our code generation process. Files are inputted into
8/3/2019 Walter Phillips Thesis
30/126
21
the Code Generator. The generated files can then compiled by the C++ compiler. This in
turn generates the executable components and the support libraries. Executable
components are linked at runtime with the supporting libraries to produce a runtime
executable system that emulates the model specification.
2.1. Goals
The primary goal of the Code Generator and supporting runtime execution
environment is relatively simple. The runtime environment must emulate the simulation
environment of M2Code/AutoFOCUS and the code generation mechanism should be able
to support any system specification to be run in this environment. The simulation
execution environment can be broken into two distinct areas, state-machine and
communication infrastructure. The state machine approach we chose to use was blocks of
conditional statements. In general, the state-machine alone does not require a complex
execution environment since it is operates on local (local to the execution thread)
variables. Preparing input and handling output for the state machine is more complex.
The communications infrastructure in our Framework should support preparing and
reading input and output data for the state machine. The state-machine generation portion
of the Code Generator can then be relatively simple.
Beyond the fundamental goal of emulating the simulation execution environment,
a number of other important qualities were outlined. First, code generation and Code
Generator complexity should be minimized, second, the code generation process should
be straightforward, and third the resulting generated code should be modular.
2.1.1. Minimize complexity
The complexity of the generated code should be kept to a minimum. This is the
reason for the modularized libraries as opposed to a large generated code files. Simplicity
in the generated code also improves readability and understandability in the same way for
example, that string-handling libraries improve readability over handling character arrays
directly. The person dealing with the higher-level code does not need an intimate
8/3/2019 Walter Phillips Thesis
31/126
22
knowledge of the underlying implementation. The supporting runtime Framework
architectures purpose is to provide a simple API for the generated code. Other benefits
arise from this modularization, the most notable of which is platform independence of the
actual generated code.
2.1.2. Straightforward Code Generation
The code generation process should be straightforward. It is difficult to produce
completely useable code for every given system and so it is desirable to allow for easy
modification, before and after the code generation process. A code generator can be a
black box that takes input, and generates output with no transparency. We decided
however, to expose through ASCII text, as much of the code generation process as
possible. The user should be able to easily understand where the code is coming from in
order to make changes. To accomplish this we utilized code templates to localize the
code generation to specific block replacement tasks, rather than complete file generation.
Standard C++ code files are modified to include tags. These tags can be easily identified
by a parsing engine and replaced with code generated.
Through templates, users can intuitively integrate their custom code up front and
have that code become part of the Code Generator output. Tag based templates also allowfor easy modification of execution flow or changes to the underlying runtime system.
This approach removes the interdependence of the runtime system code and the Code
Generator. The tag replacement mechanism tends to be a sort of black box, but to a lesser
degree than non-template based code generation systems. Code generation via tag
replacement is targeted and limited. The user can easily trace where the tag generation
code is within the Code Generators source code. Furthermore, the user can implement
new tags to perform new replacement operations.
2.1.3. Code Modularization
The underlying runtime tools used in the runtime Framework should be isolated
from the generated code through a simple API. The chosen communications platform for
8/3/2019 Walter Phillips Thesis
32/126
23
our purposes was Real-Time CORBA. The sheer complexity of the code required to
bootstrap a CORBA component was motivation enough to institute an encapsulating API
for the sake of simplifying the generated code. Of more importance for the long-term
viability of this Code Generator is the ability to interchange the underlying execution
tools without drastically affecting either the Code Generator or the generated code.
Modular code provides an abstraction of the underlying execution system, allowing the
underlying system to be changed with little or no affect on the generated code. The
underlying execution system is also isolated from changes to the generated code,
provided the changes to the generated code utilize the same set of functionalities
provided by the abstraction layer.
2.2. Code Generator Input
The Code Generator takes input from two distinct sources, template files and an
XML model specification. These files must be available to the Code Generator before it
can execute. Generic template files are prepared in advance while the XML specification
is unique to the system under development. Template files can be altered to suit the
particular system under development, but the generic files should be adequate for most
systems.
2.2.1. Templates
Template files contain the basic skeleton code of a generic system. Templates are
structured as standard C++ source code files with the addition of unique tag elements.
These unique tag elements designate places for text replacement during code generation.
Information embedded in these tags enable the Code Generator to construct the
appropriate block of code to generate for that particular section of the output C++ source
code file. In order to embed tags in C++ code, special character sequences that are not
typically found in C++ source code are used to distinctly identify these tags.
Template files can have a one-to-many relationship to their corresponding output
code files. In other words, the same template can be used to generate a number of distinct
8/3/2019 Walter Phillips Thesis
33/126
24
files that belong to the same class of file. For example, a system will have a number of
components. In the Central Locking System execution components such as the Key Fob,
Lock Manager, Crash Sensor, etc. all share the same fundamental skeleton code, only the
names and state-machine have changed. It is useful to apply a notion of inheritance to the
template files and their resulting code files. This provides consistency between
components of the same class and reduces the number of template files. This is
particularly important since the number of components is variable from system to system.
Theoretically, the number of components is infinite, although platform limitations impose
reasonable limits. In our particular implementation the number of distinct components
can range from 255 to 21840. This limitation on unique events in our particular version of
CORBA will be discussed in Chapter 7.3 below. It would be inappropriate to construct,
or even copy this many template files since many, if not all, of them will be similar. As
the system under development progresses, it maybe necessary to copy template files to
integrate custom code for a given component. For initial system development however, it
is sensible to minimize the number of template files and allow the developer to replicate
templates as necessary.
2.2.2. XML Model Specification
The XML model specification we employ is based on the format used byAutoFOCUS [HuberSchaetzSchmidt96] and contains specifications for each component
in the system, all communication channels, and each state-machine. From this abstract
specification, the Code Generator can construct the appropriate components utilizing the
corresponding template files. Template tags are replaced with the information contained
in the XML specification or with a composite of the information contained throughout
the XML specification. Simple name replacement, for things such as component names,
uses the information contained directly in the specification. For more complex
replacement the specification must be parsed extensively to extract the necessary
information. One example of a more complex block replacement would be the state-
machine code block contained in each executable components tick method.
8/3/2019 Walter Phillips Thesis
34/126
25
Figure 2-2 Example XML Specification
This is a view of the actual XML specification for the CLS projectintroduced in Chapter 1.3 above.
The nodes in Figure 2-2 have been collapsed for readability. The environment,
shown here, is a special component that contains the systems execution components. The
system model is defined hierarchal and is evident in the subcomponents node. Note the
enumeration of the system subcomponents KF, CONTROL, LM, LS, SM, and DBcontained in this node. Each of these subcomponents is represented in the graphical
modeling tool. Figure 2-3 below shows the contents of a component node. A graphical
depiction of these model components are given in Chapter 4.3 below
8/3/2019 Walter Phillips Thesis
35/126
26
Figure 2-3 XML Component Node Specification
The KeyFob component node from the above system (Figure 2-2) hasbeen expanded to illustrate its automaton which will get translated bythe Code Generator into an executable state machine. In the execution
component, this state machine will be contained in the tick() method(discussed 3.1.3 below).
The XML specification is used to define, in a platform independent manner, the
structure and behavior of the system that is to be generated. In order to facilitate the
execution of this system, the runtime environment must support the generic structure of
the system. The system details in the XML model specification, such as the enumeration
of components described above, are useful only when they can be successfully mapped
into an execution environment. This execution environment is described in Chapter 3.1
below.
2.3. Runtime System Foundation
The purpose of the runtime system is to provide an execution foundation for the
runtime components. We have additionally specified that this runtime system
Framework abstract the underlying platform. How this abstraction is accomplished is
irrelevant to the basic functionality of the Code Generator or the generated code because
8/3/2019 Walter Phillips Thesis
36/126
27
the underlying platform implementation is encapsulated and exposed via a simple API.
This encapsulation makes it possible to reuse or replace the underlying platform without
severely affecting the generated code. A number of static handwritten files were
developed to provide a basic runtime Framework to achieve this isolation between the
generated code and the underlying platform. These handwritten Framework files can be
rewritten to target other platforms while exposing the same API. The details of porting
our runtime Framework can be found in Chapter 6.
2.3.1. Runtime Framework
The Framework contains code specific to the underlying platform. In our case,
this underlying platform is Real-Time CORBA. The Framework does not contain any
code pertaining to the specific system model under development, instead it contains only
the code required to interface a generic system to the underlying platform. The reason
for this code independence is two fold. First, a compilation and deployment optimization
is gained if the Framework can be compiled as a library once and for all. Secondly, and
more importantly, it provides a clear boundary of what code should go where. Ideally, the
generated component code should have no notion of the underlying platform. Likewise,
the Framework should have no notion of the specific system to be run on it.
The Frameworks fundamental purpose is to provide simplified component
configuration methods and to handle event sending and receiving. To accomplish these
three tasks requires a great deal of code in CORBA, or any other communications
platform. The underlying CORBA code is quite extensive and has fortunately been
encapsulated in its own API. Nevertheless, it still requires much coding to build a
CORBA application. Tightly integrating this code with the component would severely
limit the ability to change platforms in the future. The Framework frees the component
code from its dependence on the underlying platform.
The Framework is compiled as a dynamically linked library to improve
compilation and deployment times. This simply means that the compiled Framework
8/3/2019 Walter Phillips Thesis
37/126
28
exists in its own file and is linked to the component at runtime. Since the Framework is
project independent, it is possible to deploy this DLL file along with the runtime support
files for CORBA. In scenarios involving embedded devices, the Framework can be
converted into a statically linked library, which can be compiled directly into the same
binary, making the executable component self-contained. This would be particularly
useful if a custom communication platform was implemented within the Framework
code. Deployment would involve simply copying the executable, rather than the
deployment of CORBA, which involves a number of files and extensive configuration.
2.4. Code Generator Output
The Code Generator outputs three basic classes of files, an Interface Definition
Language (IDL) File, the Common Library files, and Execution Components. These files,
combined with the static Framework Library introduced above (Chapter 2.3.1), constitute
the runtime system that emulates the simulation environment.
2.4.1. Interface Definition Language (IDL) File
The Interface Definition Language file is produced by the Code Generator and is
a CORBA specific requirement. It should be noted that IDL files are not unique to
CORBA. They are simply a means to abstractly define, or model, a system. The purposeof an IDL file in a CORBA project is to provide a specification for the objects that
CORBA will manage. For our purposes, these CORBA objects directly map to a
component. We define a runtime component as simply an executable combination of
driver code and a CORBA object. The IDL file is used by CORBA to produce the stub
and skeleton code that will enable each defined object to interface with the CORBA
backend. This stub and skeleton code is produced my means of an IDL compiler that is
provided with CORBAs development tools.
The IDL compiler is a type of code generator in itself as it takes an abstract
specification and generates code that simplifies access to the complex CORBA backend.
In addition to the stub and skeleton code, a number of client and server files are
8/3/2019 Walter Phillips Thesis
38/126
29
produced. These files provide access to the various services offered by CORBA. Access
to CORBA can be attained through either the use of the stub/skeleton code, via the
client/server interfaces, or by a combination of the two. Our runtime component objects
inherit from CORBA objects contained in the client/server files and so we simply need to
compile them along with the components. We do not make use of the stub/skeleton code.
2.4.2. Common Library
The Common Library is a repository for code that is common to all components,
project specific and also platform specific. The Code Generator dynamically produces its
source files through the same template mechanism that produces the component files.
The Common Library and Framework library could be compiled together, but were left
as distinct libraries to clearly identify what code belongs where. The Common Library
addresses the inability to completely detach the underlying platform from the execution
components. It is possible to develop a communications platform that does allow for a
clean separation of code, CORBA unfortunately does not. Furthermore, there is still a
need for a repository of project specific code that is common to all components.
The initial need for a Common Library came about from compilation inefficiency
stemming from the IDL file presented above. The compilation process of CORBAinvolves generating a number of skeleton and client/server support code files from the
given IDL file. These support files must be compiled into the component in order to gain
access to the CORBA environment. Compiling each of these files into the executable
components was time consuming and redundant. While this was not of critical concern, it
was a motivating factor in building a library that contains code common to all
components, but that is also dependent on the underlying platform. This allows the
execution components to maintain their platform independence while bridging the gap
between the platform independence desired by components and the project independence
desired by the Framework.
8/3/2019 Walter Phillips Thesis
39/126
30
The Common Library contains common type definitions such as enumerated
types corresponding to event types, etc. It also contains utility functions that aid in
converting an event type from a number to a readable string. Interfaces for marshalling
and unmarshaling event data via CORBA operations are provided, the implementation
details of which will be discussed later. The Common Library is compiled as a
dynamically linked library, in the same manner as the Framework. The Common Library
could also be compiled as a statically linked library and then compiled directly into each
executable component. It was left as a standalone DLL file solely to improve compilation
time.
Figure 2-4 CommonLibrary Files
The Common Library contains a mix of IDL compiler generated code files
(SystemC.* and SystemS.*) and dynamically generated code files fromthe Code Generator (CLS_common.* and System.idl). Duringcompilation, a custom build step of the System.idl invokes CORBAs IDL
compiler to generate the SystemC.* and SystemS.* files, which aresubsequently compiled into the CommonLibrary.
8/3/2019 Walter Phillips Thesis
40/126
31
2.4.3. Runtime Components
Figure 2-5 CORBA Component Inheritance
This inheritance diagram was generated for the CLS example via Doxygen
and illustrates how the project components (on the right) are related to theFramework (AbstractComponent and TickableComponent) and theCORBA specific objects (POA_CLS::[ComponentName]) created via the
IDL compiler discussed above.
The execution components make use of the Framework and Common Library
discussed above. The actual code contained in the execution components is fairly simple,
as most of the complex operations have been pushed into the supporting libraries.
Components are derived from the corresponding template files and are the result of the
tag replacement performed by the Code Generator. Component types are similar in that
they all utilize the common execution and communication Framework outlined above.
They differ in their roles and operations they perform during the execution of the system.
There are three main types or classes of components, the environment, the execution
components, and the monitor. With the exception of the monitor, all components are
derived directly out of components defined in the model.
2.4.3.1. Environment
The environment component is a specialized form of the model component. Its
primary role in the runtime system is to manage control messages for startup events. As a
8/3/2019 Walter Phillips Thesis
41/126
32
result, the environment component contains specialized code for this purpose. The
environment does not perform state transitions in the model and so the executable does
not contain a model-derived state-machine. The processing of startup events can be
considered a state-machine, but is specific to our execution Framework. Aside from the
major distinction of lacking a state-machine, the environment code base is largely
identical to that of the other components.
2.4.3.2. Execution Components
Components are the executable units of operation that perform specific tasks
defined by the corresponding model components state-machine. The tick() event
contains the state machine and is called upon receiving an input from all attached
components. In order to call the tick method, the component must receive all input
messages from all attached components. To do this, the component must be aware of the
events it expects. Keeping track of the input messages is handled by two mechanisms.
First, CORBAs conjunct event groupings govern event delivery. This alone would be
sufficient, but requires a strict dependency on this CORBA specific event-grouping
feature. A second means for handling event groupings is contained in the components
handleEvent() method. Events are counted and when the expected number of inputs is
reached, the tick method is called. This very rudimentary implementation was included todemonstrate input event management could be handled in different levels of the
execution hierarchy, in the underlying platform, in the component, or at any point in
between.
2.4.3.3. Monitor
The model does not define the monitor component. It is purely a diagnostic tool
used to interface with the underlying communications infrastructure. It does not contain a
state-machine because it does not perform any model-defined tasks. The monitor is
unique in that it listens to all events individually. The execution components described
above listen to a subset of events, which are tagged as grouped events. This allows the
developer to monitor the internal system messages. The monitor also has the ability to
8/3/2019 Walter Phillips Thesis
42/126
33
actively submit events on the behalf of other components. Although this injecting of
events is useful, the monitor is primarily a passive component because the system can
become unstable if events are inappropriately injected.
The monitor was developed with a user interface and so it can be useful for kick
starting a system that has not yet implemented custom interfaces for the execution
component. A primary example is the Central Locking Systems Key Fob component.
The Code Generator does not produce code to interface with user input. This task is left
to the developer as that code is specific to the hardware buttons. In lieu of Key Fob
interface code, the monitor can provide a convenient surrogate input interface until a
custom solution is created and integrated into the generated code.
Because the monitor has a user interface, its runtime architecture differs slightly
from the standard component code. Any execution component described above could be
modified to provide a similar windowed interface. The monitor demonstrates the
flexibility and relative ease of integrating the generated component code with other
technologies. The monitor component is made up of two code modules. The component
code itself is almost identical to the other components and contains the methods to send
and receive events. This component code is compiled into a dynamically linked library
rather than a standalone executable. The second code module is a windowed executable
written in C#. This executable invokes the methods exposed by the monitor component
code contained in the DLL. Encapsulating the component code, as with the Framework
code, affords the user interface a form of independence from the underlying component
and in turn, the underlying communications platform. The monitor component can be
used as an example for constructing custom interfaces for the system components. Since
our target application is in the automotive domain, windowed interfaces are not likely to
be required. Instead the hardware-based user interface triggers are likely to be integrated
directly into the component source code itself.
8/3/2019 Walter Phillips Thesis
43/126
34
3. Design Flow, Tools, and Artifacts
This chapter discusses the modeling tool and how the runtime architecture was
designed to simplify the Code Generator architecture. The general design flow begins by
capturing the requirements of the system to be developed. From these requirements, amodel is constructed using a tool called M2Code. M2Code is a graphical modeling tool
that allows the user to specify system structure and behavior. M2Code also shares a
common model specification format with another modeling tool called AutoFOCUS. The
model is then subjected to rigorous validation, verification, and testing to uncover flaws
in the design. Once the model is prepared, and logically correct, it can be translated into
executable code. Our tool takes the abstract model specification and translates it into a
form that is executable on the Common Object Request Broker Architecture (CORBA).
M2Codeor
AutoFOCUS
CodeGenerator
RuntimeExecution
Environment
XML ModelSpecification
GeneratedSource Code
C++Compiler
Figure 3-1 Code Generator Flow - Overview
This diagram shows the general linear flow path from model toexecutable. Rounded blocks denote tools while cornered blocks denotedata artifacts.
3.1. Modeling Tool
To build the model itself, and produce the abstract specification, we utilize one of
two modeling tools called M2Code and AutoFOCUS. Other comparable modeling
systems mentioned in the Related Work Section 1.6 above do not easily provide access
to their internal code generation and execution system. For this reason we must re-implement the means to convert an abstract model specification to executable code,
integrating the real-time specifications along the way. For this reason, the code
generation process is detached from the modeling tools. Abstract model specification,
through the use of an exported XML file, allows our Code Generator to function
34
8/3/2019 Walter Phillips Thesis
44/126
35
independently from the modeling tool. Our desire to integrate real-time specifications on
top of the model is the motivation for developing a custom Code Generator. Our Code
Generator relies heavily on AutoFOCUS specification and testing infrastructure, but is
independent in terms of execution. In fact, the dependency on AutoFOCUS is being
reduced by concurrent development of a tool called M2Code [KrgerGuptaMathew04].
AutoFOCUS was developed at the Technische Universitt Mnchen (TMU)
[AFWEB] and is based of the semantics of FOCUS. Of particular interest is the fact that
AutoFOCUS is freely available. Although more advanced tools such as Rational Rose,
Rhapsody, Tau, and the Nucleus BridgePoint suite from Mentor Graphics exist, they are
closed systems and as such are not suitable for our research goals. We aim to integrate
real-time property specification early in the model development phase. In order to utilize
existing modeling languages and their development tools our real-time specifications
must either be integrated into the language itself, or provided as a supplementary
specification. While this integration need not be implemented at the level of the modeling
language itself, we must have access to the internal specification and implement our own
translation between the model and specification executable.
3.1.1. Common Model SpecificationA common specification format exists between the various tools in the tool-chain
in the form of an XML model specification file based on that defined by AutoFOCUS
[KrgerGuptaMathew04] and modified to suit our purposes. Code generation is the
process of transforming this abstract specification of the system into compliable and
executable code. This abstract specification is somewhat analogous to a compiled
language, such as C or C++ in that a general specification is translated into machine
specific executable code. In effect, our Code Generator is a compiler for the abstract
model specification [Mller03], and as such shares some similarity (symbol table, etc.)
with actual compilers.
8/3/2019 Walter Phillips Thesis
45/126
36
3.1.2. Model Simulation & Validation
We began using AutoFOCUS as the core-modeling environment because it
provides useful tools for simulation and validation, both of which are critical in
uncovering bugs early on in the development cycle. We have since employed our own
modeling tool, namely M2Code and our own extensions to the model specification
format. Although not entirely analogous, model validation done by M2Code or
AutoFOCUS can be thought of as pre-compiler tools for C such as Lint [SUN05]. The
purposes of the simulation and validation tools are to prepare a reasonably correct
specification in both form and content. The simulators fundamental execution model is
fairly simple and so we can make the following assumption; if the execution environment
of our generated code emulates that of the simulation environment, we will have
produced an executable system that is as correct as the system we observed in thesimulation environment. In effect, our executable system is another sort