UML, Embedded Systems, and
Application Frameworks
Shang-Wei Lin, Chun-Hsian Huang, and
Pao-Ann Hsiung
Embedded Systems Laboratory
National Chung Cheng University
Taiwan
1
Outline
• UML and Embedded System Design
• UML Model-Driven Development
– Rhapsody
• Embedded System Application Framework
– VERTAF
2
Outline
• UML and Embedded System Design
• UML Model-Driven Development
– Rhapsody
• Embedded System Application Framework
– VERTAF
3
UML and Embedded System Design
•
•
•
•
Introduction
Embedded System
UML
Research Projects for Embedded Software
4
Introduction
• Embedded systems are becoming more and
more pervasive in our daily life
• The functionalities of embedded systems are
also becoming more and more complex
• Correctness is difficult to verify
5
General Purpose vs.
Embedded Systems
General-purpose
software
Embedded Software
Architecture
Independent
Dependent
Purpose
General-purpose
Specific-purpose
Memory
Large
Small
Processor computing
power
Strong
Weak
Real-time
No (usually)
Yes (usually)
6
Unified Modeling Language
• UML is a standardized general-purpose modeling
language in the field of software engineering
• A set of graphical notations for creating abstract
models of concrete systems
• Object-Oriented Analysis (OOA)
• Object-Oriented Design (OOD)
7
UML (cont’d)
• UML and object-oriented technology are quite
suitable for modeling embedded software
• However, the following have to be considered
– Target architecture
– Real-time characteristics
8
Research Projects for Embedded
Software
•
•
•
•
MoBIES
HUGO
DESS
VERTAF
9
MoBIES
• Model-Based Integration of Embedded
Systems
• Supported by USA DARPA
• Consists of several subprojects
10
MoBIES (cont’d)
• Subprojects
– AIRES (Automatic Integration of Reusable Embedded
Software)
• Automatically generates a run-time model from a structural
model through several metamodels
– Software architecture
– Platform
–…
– Time Weaver
• Captures para-functional properties into models of different
semantic dimensions
– Event flow
– Concurrency
–…
11
HUGO
• Developed by Germany’s Ludwig-Maximilians
University
• Model checking statecharts against collaborations
• Code generation
• No scheduling
12
DESS
• Developed by EUREKA-ITEA
• Only provides guidelines for incorporating
various kinds of tools into the design process
• Neither real implementation of the concepts
nor any toolset is provided by DESS
13
VERTAF
• Developed by Embedded Systems Laboratory,
National Chung Cheng University, Taiwan
• An application framework that integrates
– UML Modeling
– Formal Software Synthesis
• Scheduling
• Code Generation
– Formal Verification
• Model Checking
14
Outline
• UML and Embedded System Design
• UML Model-Driven Development
– Rhapsody
• Embedded System Application Framework
– VERTAF
15
Rhapsody
•
•
•
•
•
•
•
Introduction
Rhapsody for RTOS
Rhapsody Desktop
Target Platform
Rhapsody RTOS Adapter
Adapt Rhapsody to a New RTOS
OS Services for the Applications
16
Introduction
• Include a graphic editor for each of the UML
diagrams
– Use case, sequence, collaboration, object model,
component, state machine and activity diagrams
• Not only capture the design of the system but
also generate implementation code
– C, C++, Java and Ada
17
Introduction (cont’d)
• Provide Model-Driven Development (MDD)
environment based on UML 2.1
– Systems and software development of real-time and
embedded applications
• Can use an iterative design approach
– Software can be constantly executed and validated
• Can rapidly target the platform independent
application model to a real time embedded
operating system
18
Rhapsody for RTOS
• Can construct portable and technology
independent systems via
– Generation of application code from platform
independent models
– Object eXecution Framework (OXF)
– Use of OS-specific adaptors for most commercial
RTOSs
19
Rhapsody for RTOS (cont’d)
Source Code
Compiler and Linker
Model Entries
Model Compiler
Platform-Independent
Applications
Platform-Independent
Framework
OS-Dependent
Adapter
Model Execution
RTOS
Model Tester
Microprocessor
Model-Entry
Model
Animation Rhapsody Desktop
Target Platform
20
Rhapsody Desktop
• Model-Entry
– enter the PIM using standard UML diagrams
• Model Compiler
– generate the source for the selected language and
compiler
• Model Tester
– simulate and monitor the execution of the PIMgenerated application
21
Target Platform
• PIM Framework
– a real-time PIM framework provided by Rhapsody
• OS-Dependent Adapter
– a light-weight OS-specific adapter layer for
handing interactions with the underlying RTOS
22
Rhapsody RTOS Adapter
Rhapsody RTOS Adapter
Generated Application
Platform-Independent
Applications
Platform-Independent
Framework
OXF (Object eXecution Framework)
OS-Dependent
Adapter
OS Abstraction Layer
RTOS
RTOS
Microprocessor
23
Adapt Rhapsody to a New RTOS
Rhapsody OXF Source Code
OS Abstraction Layer
Abstract OS Classes
OS Environment
Makefile
OXF Libraries
OS Environment
Framework
Depend on
Create
24
Adapt Rhapsody to a New RTOS
(cont’d)
Application
Load
Module
Development
Properties
Generated
Makefile
OXF Libraries
Rhapsody
Generated
Source Codes
25
OS Services for the Applications
• Tasking services
– createOMOSThread(), createOMOSWrapperThread()
• Synchronization services
– OMOSMutex(), OMOSSemaphore()
• Message queues
– OMOSMessageQueue()
• Communication port
– OMOSConnectPort(), OMOSSocket()
• Timer service
– OMOSTimer()
26
Outline
• Unified Modeling Language (UML)
• UML Model-Driven Development
– Rhapsody
• Embedded System Application Framework
– VERTAF
27
VERTAF
•
•
•
•
•
•
Background
Issues and Solutions
Framework Architecture
Framework Flow
Framework Phases
Application Examples
28
Background
• Verifiable Embedded Real-Time Application
Framework (VERTAF)
• A long-term research project of Embedded
Systems Lab, National Chung Cheng University,
Taiwan
• Collaboration among several universities in
Taiwan
29
Background (cont’d)
• Portions of work on this research project
published already in several conferences and
journals:
– Scheduling: CODES’99, CODES’01, APSEC’01,
CODES’02, APSEC’02, RTCSA’02, CODES’03,
RTCSA’03, IEEE-TCE’04
– Verification: CODES’99, ECRTS’99, TACAS’99,
COMPSAC’00, IEE-DCT’00, JSA’00, IEEE-TC’02
– Framework Architecture: RTAS’01, ISORC’02, IEEETSE’04, EUC’07, CLSS’07, JSPS’08
30
Issues and Solutions
Based on user given specifications for
real-time embedded software, can we
automatically
design, verify, and generate code?
Yes, under some constraints!
31
Issues and Solutions (cont’d)
• How to specify real-time embedded software
requirements?
– UML models
• Selected three types of models
• Restricted as well as enhanced
– Formal Semantics
• For synthesis and verification
– Specification Guidelines
• For automatic analysis and design
32
Issues and Solutions (cont’d)
• What kinds of models can be used for each
design phase?
– Specification: Formal UML models
– Synthesis: Real-Time Petri Nets
– Verification: Extended Timed Automata
• Model Continuity Problems:
– Semantics Equivalence Checking
• UML vs. Real-Time Petri Nets
• UML vs. Extended Timed Automata
33
Issues and Solutions (cont’d)
• What is the Control-Flow? When to verify
and when to synthesize?
– Framework Approach
• A semi-complete application
– High-level architecture reuse
• Inversion of control
– Users fill in objects and functionalities, framework takes care
of the software flow control
– Proposed Flow
• First, synthesize and then verify!
– Smaller state-space
34
Issues and Solutions (cont’d)
• How to formally synthesize and verify?
– Synthesis
• Scheduling to satisfy local deadlines, global deadlines,
memory constraints, power constraints
– Verification
• Model Checking
– Interface Verification
– Assume-Guarantee Reasoning
– Abstraction Techniques
35
Issues and Solutions (cont’d)
• How to automatically generate code?
– Code generation
• Application
– From formal UML models
• Scheduler
– From scheduled Petri Net models (derived from UML)
– Code architecture
• Multi-layered
• Portable, Efficient
36
Framework Architecture
UML Real-Time
Embedded Object Model
Reusable
Components
Scheduler
Generation
Formal
Verification
LQS
Scheduling
HW Architecture
Mapping
Automatic Code
Generation
37
Framework Flow – Front End
V
e
r
i
f
i
c
a
t
i
o
n
Modeling
State Chart
UML Model
Class
Diagram
Sequence
Diagram
Petri-net
Generation
Automata
Generation
Scheduler
Generation
Extracted
scheduling
information
Schedule
Scheduler
Generation
Verify
Yes
Schedulable
No
Display counterexample in UML
model
No
Specification
satisfied
Display unschedulable
information
S
c
h
e
d
u
l
i
n
g 38
Framework Flow – Back End
Display counterexample in UML
model
No
Specification
satisfied
Yes
Display unschedulable
information
Front End
Back End
Architecture
Mapping
Component
Mapping
Code Generation
Code
Generation
Application
Codes
39
Framework Phases
•
•
•
•
•
•
UML Modeling Phase
Scheduling Phase
Scheduler Generation Phase
Formal Verification Phase
Hardware Architecture Mapping Phase
Code Generation Phase
40
UML Modeling Phase
Modeling
State Chart
UML Model
Class
Diagram
Sequence
Diagram
Petri-net
Generation
Automata
Generation
Scheduler
Generation
Extracted
scheduling
information
Schedule
Yes
Verify
Schedulable
No
Display counterexample in UML
model
No
Specification
satisfied
Display unschedulable
information
41
UML Modeling Phase (cont’d)
• To specify requirements by a system model
• Three diagrams chosen from UML:
– Class Diagram with Deployments
– Extended Sequence Diagrams
– Timed Statecharts
• Modifications for modeling real-time
embedded software requirements
– CD: Hardware deployments
– SD: State marks, control extensions
– SC: Timing control keywords, real-time constraints
42
Scheduling Phase
State Chart
UML Model
Class
Diagram
Sequence
Diagram
Petri-net
Generation
Automata
Generation
Scheduler
Generation
Extracted
scheduling
information
Schedule
Yes
Verify
Schedulable
No
Display counterexample in UML
model
No
Specification
satisfied
Display unschedulable
information
S
c
h
e
d
u
l
i
n
g 43
Scheduling Phase (cont’d)
• To ensure feasibility of a system
• Low-Power Quasi-Dynamic Scheduling (LQS)
– Generate Power-Aware Real-Time Petri Net models
from UML sequence diagrams
– Decompose into computations
– Statically schedule each computation to satisfy
•
•
•
•
Time (local deadlines, global deadlines, periods)
Memory
Energy (I/O device, microprocessor)
Task precedence relationships
44
Scheduler Generation Phase
State Chart
UML Model
Class
Diagram
Sequence
Diagram
Petri-net
Generation
Automata
Generation
Scheduler
Generation
Extracted
scheduling
information
Schedule
Scheduler
Generation
Verify
Yes
Schedulable
No
Display counterexample in UML
model
No
Specification
satisfied
Display unschedulable
information
45
Scheduler Generation Phase (cont’d)
• To ensure the generated application follows
the scheduling result (static LQS schedules)
• Scheduler
– Generated from the scheduled task sequence
– Two forms:
• An extended timed automata (for verification)
– Communications among the system ETA models
• A piece of software code (for code generation)
– Schedules and dispatches object tasks
– Implementations: SST, TinyOS (sensor network)
46
Formal Verification Phase
V
e
r
i
f
i
c
a
t
i
o
n
State Chart
UML Model
Class
Diagram
Sequence
Diagram
Petri-net
Generation
Automata
Generation
Scheduler
Generation
Extracted
scheduling
information
Schedule
Yes
Verify
Schedulable
No
Display counterexample in UML
model
No
Specification
satisfied
Display unschedulable
information
47
Formal Verification Phase (cont’d)
• To ensure the functional correctness of the generated
real-time embedded software
• Model Checker: State Graph Manipulators (SGM)
– System Model
• A set of ETA translated from UML statecharts
• A scheduler ETA generated by scheduling sequence diagrams
– System Properties
• TCTL formulas translated from UML/OCL specifications
– Counterexample
• A sequence diagram from ETA counterexample (computation run)
48
Hardware Architecture Mapping Phase
Display counterexample in UML
model
No
Specification
satisfied
Yes
Display unschedulable
information
Front End
Back End
Architecture
Mapping
Component
Mapping
Code Generation
Application
Codes
49
Hardware Architecture Mapping Phase
(cont’d)
• Reusable component models
– Drivers, library modules, object files
– Functional: state diagrams, …
• For verification
– Non-functional: response time, transfer rate, …
• For scheduling
• Portable generic interface for components
– init(), reset(), read(), write()
50
Code Generation Phase
Display counterexample in UML
model
No
Specification
satisfied
Yes
Display unschedulable
information
Front End
Back End
Component
Mapping
Code Generation
Code
Generation
Application
Codes
51
Code Generation Phase (cont’d)
Multi-layered code generation
52
Application Example
• Entrance Guard System with Mobile and
Ubiquitous Control (EGSMUC)
• An embedded system for controlling the
entrance of a building
– Password
53
Application Example (cont’d)
• User-specified UML Models
– 1 Class Diagram with Deployments
– 9 Extended Sequence Diagrams
– 6 Timed Statecharts
• Models Generated
– 2 Petri Net model for scheduling
– 6 Extended Timed Automata for verification
54
EGSMUC Class Diagram
Keypad
1
+reset() : bool
+init() : bool
+read() : int
1
1
-Display
1
1
Input
GetData
1
Display
SendData
FlashRom
1
-GetData
1
1
-SendData
1
1
1
1
DBMS
-SendData
1
1
MediaCenter
+reset() : bool
+init() : bool
+read() : unsigned char*
+write() : bool
1
-GetData
Codec
Checker
1
1
1
1
1
1
1
-SendData
-DisplayData
LCD
-GetResult
Camera
1
1
+reset() : bool
+init() : bool
+write() : bool
+clear() : bool
Web Server
-SendResult
Controller
1
1
1
1
1
1
1
1
Audio
1
LED
1
+reset() : bool
+init() : bool
+soundAlarm() : bool
+stop() : bool
+read() : unsigned char*
+write() : bool
-control
1
Actuator
1
1
-Control
1
1
-control
+reset() : bool
+init() : bool
+write() : bool
Network Adapter
+reset() : bool
+init() : bool
55
EGSMUC Sequence Diagram (1 of 9)
56
EGSMUC Statechart (1 of 6)-controller
[select==3]
after: Selection_TO
[(ALARM_ON && select == 2) || (~ALARM_ON && select == 1)]
Stop_Alarm
Control
Read_PW
Request_ID
[ALARM_ON
&&
select == 1]
Clear
/ Controller_Send_Input_SIG
Store
[select == 2 && ~ALARM_ON]
[result == ID_ERROR
&& ~ALARM_ON] / Controller_Send_Input_SIG
Read
[result == supervisor]
Selection
[result == PWD_ERROR
&& ~ALARM_ON
]
Checker_Send_Controller_SIG
Show_MSG
Record
/ Controller_Send_Input_SIG
[ALARM_ON
&& result != supervisor] / Controller_Send_Input_SIG
Close_Door
after: Door_TO
[result == PWD_OK
&& ~ALARM_ON]
[Error_conut
>= MAX_ERROR]
Open_Door
[Error_count < MAX_ERROR] / Controller_Send_Input_SIG
/ Controller_Send_Input_SIG
Select:
1. Stop alarm
2. Create a new ID
3. Exit
Start_Alarm
57
EGSMUC Petri Net Model (1 of 2)
58
EGSMUC Generated Extended Timed
Automaton (Controller)
59
EGSMUC Verification
• Some security holes found after verification
– Supervisor behaviors were missing in the UML
sequence diagrams
– The use-case of a non-existent user identity was
missing in the UML statecharts
60
EGSMUC Code Generation
• Code was generated on QF (quantum
framework), a middleware for embedded
systems
– 16 files generated as application code
– One file generated as scheduler code
– User had to write only around 6.2% of code
61
Conclusions
• UML can be used for modeling and design of
embedded system software
– Rhapsody
– VERTAF
• Future work
– SysML: requirements diagram, etc.
– Multicore embedded software
– Reconfigurable systems
62