Walter Phillips Thesis

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


2/126

ii


3/126

iii

The thesis of Walter Phillips is approved

_____________________________________________

_____________________________________________

_____________________________________________

Chair

Geoffrey M. Voelker

Stefan SavageIngolf Krueger, Chair

University of California, San Diego

2006


4/126

iv

Dedication

Harry J. Phillips1932-2004


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


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


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/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


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.


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


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


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


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


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


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


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


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.


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.


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.


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.


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.


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


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


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.


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


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


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.


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


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


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


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


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


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.


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


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


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


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


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.


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.


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


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


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.


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


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.


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

Walter Phillips Thesis

Documents

Transcript of Walter Phillips Thesis