Overview of Embedded
Software Research at USC
CSCI 599 – Software Engineering
for Embedded Systems
September 3, 2002
Architectural Abstraction
Cl ock :
Cl ock
8: request
Cl ockConn
9: notification
Warehouse
10: notification
Del iveryPort
Vehicle
7: request
4: request
1: request
3: request
RouterConn
2: notification
CargoRouter
5: request
GraphicsConn
6: notification
GraphicsBinding :
GraphicsBinding
Why Software Architecture?
•
•
•
•
•
•
•
Early, high-level system model
Stakeholder understanding and communication
Focus on specific system properties
Separation of concerns
Early analysis and simulation
Tool-supported implementation
Improved processes and project management
Architectural Style
• Recurring structural, behavioral, and interaction
patterns
– Design vocabulary and grammar
– Envelope of allowed change
– Guarantee of desirable properties
• Generalization from specific experience
• Enables proper balance of
– Intuition
– Method
– Theft
The C2 Architectural Style
• Event-based communication among autonomous
components, mediated by active connectors
• Composition
– No component-component links
– Separation of computation from communication
– Asynchronous, implicit invocation
via connectors
– Substrate independence
Authorized
• Concurrency
• Distribution
• Heterogeneity
User
Authorized
User
Verify User
Information
Accept
Login
Event
Window
Opened
Window
Closed
C2 Connectors

Enable key C2 properties


Implement message passing
policies
Support message registration and
filtering

Polymorphic interfaces
Ci.bot = Ci.bot_in 
Ci.bot_out
a bq
Bj.top_out = f(Bj.bottom_in)
ab
q
a b c pq
a bcpq
a bc

pq
Bj.bottom_in =
i
Cbi.top_out
Ci.top = Ci.top_in 
Ci.top_out
Programming-in-the-Small-and-Many
– Prism
Prism Challenges
• Resource constraints
– Demand highly efficient computation,
communication, and memory footprint
– Demand unorthodox solutions
• e.g., off-loading components
• Hardware and software heterogeneity
–
–
–
–
–
Proprietary operating systems
Dialects of programming languages
Device-specific data formats
Lack of support for inter-device interaction
Lack of support for code mobility
Prism Style
• Directly leverages C2
• Peer-to-peer interactions
– Side component ports, peer
connectors, peer messages
– Preserves substrate independence
Palm-3
• Architectural self-awareness
Palm-2
Requests
• Admin component
• Continuous analysis component
• Messages
–
–
–
–
Application data
Component content
Architectural model
Subscription messages
Notifications
– Application level
– Meta level
A
B
PC
D
iPAQ
C
Palm-1
Peer
Prism Connectors
• All Prism connectors are able to exchange data,
code, and architectural models
• Two communication paradigms
– Client-server
– Peer-to-peer
• Four connector categories
–
–
–
–
Basic
Border
Secure
Multi-versioning
Basic Connectors
• Synchronous and asynchronous interaction
• Message routing policies
– Unicast
– Multicast
– Broadcast
• Support for real-time constraints
• Delivery guarantees
Border Connectors
• Spanning contexts
– Address spaces
– Processes
– Machines
•
•
•
•
•
Marshalling and unmarshalling of information
XML encoding
Wireless interaction (IR)
Network link monitoring
Mechanisms
– CORBA, RMI, Sockets, ILU, Q, Polylith
Secure Connectors
• Useful in connector-to-connector interaction
• Reusable security module
– E.g., used in IR border connector
• Multiple such modules would allow altering
security policy on the fly
• Open issue
– Mismatched security policies by interacting
connectors
Multi-Versioning Connectors
• Ensure reliable component upgrades
• Monitor multiple versions of a component
– Correctness
– Performance
– Reliability
• Functional behavior of system unaffected
– Performance possibly affected
– Possible impact on real-time systems
• Special case – disconnected operation
Support for Implementing Architectures
• Software architectures provide powerful high-level
concepts
– components, connectors, events, configurations, constraints
• Programming languages provide powerful low-level
constructs
– variables, arrays, pointers, procedures, objects
• Bridging the two often is an art-form
• Existing “middleware” technologies
– support some architectural concepts (e.g., components, events)
– but not others (e.g., connectors, topologies)
• What is needed is “architectural middleware”
Implementing Prism-Style
Architectures – PrismMW
• Extensible framework of abstract classes for
Prism concepts
– component, connector, communication port, message
– implements interconnection rules and communication
protocols
– supports event monitoring and filtering
– enables rapid construction of Prism-style applications
– allows developers to focus on application-level issues
– implemented in
• Java JVM and KVM
• Embedded Visual C++
PrismMW Design
Size
under 2KB at
system start-up
A
A r c h it e c t u r e E v
e n tC o n s ta n ts
#sid e
IC o n n e c t o r
C o n n e c to rT h re a d
C o m p o n e n tT h re a d
# to p
# b o tto m
IC o m p o n e n t
IA r c h it e c t u r e
C o n n e c to r
B
A r c h it e c t u r e
A r c h ite c tu r e A d a p t e r
C
A d m in C o m p o n e n t
S e r ia liz a b le
# s c a f f o ld
IS c a f f o ld
M essage
C om ponent
Performance
300MHz PentiumII
Java KVM framework
two components
one connector
one thread
one million messages
~ 13 seconds
+
+
+
+
+
______________________________________________________________________________________________________
B r ic k
N o t if ic a t io n
R equest
D
A d d re s s
t o p Id
Peer
b o t t o m Id
s id e Id
Adjustable threading
Adjustable scheduling
PrismMW
API
Component
Connector
Component(name : String)
Component()
Component(name : String, junk : String)
send(r : Request) : void
send(n : Notification) : void
Architecture
Connector()
Connector(name : String)
handle(r : Request) : void
handle(n : Notification) : void
ConnectorThread
ComponentThread
Architecture()
Architecture(name : String)
Architecture(name : String, n : int)
start() : void
stop() : void
shutdown() : void
handle(r : Request) : void
handle(n : Notification) : void
addComponent(comp : Component) : void
addConnector(conn : Connector) : void
weld(conn : Connector, comp : Component) : void
weld(comp : Component, conn : Connector) : void
weld(conn1 : Connector, conn2 : Connector) : void
removeComponent(comp : Component) : void
removeConnector(conn : Connector) : void
setThreadCount(n : int) : void
getThreadCount() : int
threadFunction() : void
notifyArchitecture() : void
searchFIFO(f : SynchronizedFIFO, o : Object) : Object
ConnectorThread(n : String)
ComponentThread()
ComponentThread(s : String)
run() : void
Message
Message()
Message(name : String)
name() : String
addParameter(parameterName : String, parameterValue : Object) : void
hasParameter(Name : String) : boolean
removeParameter(Name : String) : void
getParameter(Name : String) : Object
Request
Request()
Request(Name : String)
Notification
Notification()
Notification(Name : String)
Internal Working of Prism-MW
Component A
Component B
handleRequest
Thread Pool
Component D
send Request
Connector C
X
R N R R N R
1 1 2 3 2
R
Example Prism Application
Another View of the Application
Arch ite ctu re E v
Arch ite ctu re E v
e n tC o n s ta n ts
e n tC o n s ta n ts
# to p
IC o n n e cto r
Map
Repository
IArch ite ctu re
IC o m p o n en t
C o n n e cto rTh re a d
C o n n e cto r
A rch ite ctu re
# b o tto m
IArch ite ctu re
IC o m p o n en t
Admin
Component
Arch ite ctu re Ad a p te r
# to p
IC o n n e cto r
Available
Troops
Repository
# b o tto m
Com ponent
C o n n e cto rTh re a d
C o n n e cto r
Admin
Component
A rch ite ctu re
Arch ite ctu re Ad a p te r
C o m p o n e n tTh re a d
Map
Display
S e ria liza b le
C o m p o n e n tTh re a d
# s ca ffo ld
ISc a ffo ld
Strategy
Analyzer
Me ssa g e
+ b o tto m Id
+ to p Id
Troops
Deployer
Ad d re s s
(f rom C 3.util)
N o tifica tio n
Map
Display
B r ick
(f rom io)
Com ponent
Reques t
Admin
Component
M
S e ria liza b le
B r ick
# s ca ffo ld
ISc a ffo ld
(f rom io)
Me ssa g e
+ b o tto m Id
+ to p Id
Ad d re s s
(f rom C 3.util)
N o tifica tio n
Reques t
Map
Display
Arch ite ctu re E v
Arch ite ctu re E v
e n tC o n s ta n ts
e n tC o n s ta n ts
IC o n n e cto r
# to p
IC o n n e cto r
# to p
# b o tto m
IArch ite ctu re
Strategy
Analyzer
C o n n e cto rTh re a d
IC o m p o n en t
C o n n e cto r
A rch ite ctu re
# b o tto m
M
Admin
Component
Arch ite ctu re Ad a p te r
Com ponent
C o m p o n e n tTh re a d
B r ick
Map
Display
S e ria liza b le
# s ca ffo ld
ISc a ffo ld
(f rom io)
Me ssa g e
+ b o tto m Id
+ to p Id
Ad d re s s
(f rom C 3.util)
N o tifica tio n
Reques t
M M M M
M
M
MM
Strategy
Analyzer`
C o n n e cto rTh re a d
M
IArch ite ctu re
Admin
Component
IC o m p o n en t
C o n n e cto r
A rch ite ctu re
Arch ite ctu re Ad a p te r
Com ponent
C o m p o n e n tTh re a d
Map
Display
S e ria liza b le
B r ick
# s ca ffo ld
ISc a ffo ld
(f rom io)
Me ssa g e
+ b o tto m Id
+ to p Id
Ad d re s s
(f rom C 3.util)
N o tifica tio n
Reques t
Deployment Support – PrismDE
–
Leverages ComponentContent
messages
– Assumes preloading a skeleton
configuration on each device
– Implemented as an extension to Visio
(COTS)
add(DataRepository: source PC): PC
weld(TopBorderConnector,C_IPAQAvailableTroops): iPAQ
peerWeld(G_AvailableTroops,SideBorderConnector): Palm-1
Support for Mobility
• Component Content messages containing mobile code
• Process
– Possible detachment of the migrant component (using unweld
and peerUnweld )
– Possible unloading of the migrant component (remove)
– PC’s Admin Component - sends the migrant component
– Receiving Border Connector(s) forward it to the local Admin
Component which reconstitutes the migrant component
– Each Admin Component attaches the migrant component to
the architecture (add, weld, and peerWeld)
Support for Disconnected Operation
• Minimize the risks associated with disconnection
• Maximize availability / minimize degradation
– Reroute communication
– Fetch components before disconnection occurs
• Relevant factors
–
–
–
–
–
–
–
Statefulness
Event frequencies across network links
Dependencies of candidate components
Type of disconnection
Time to disconnection
Required and available memory
Network bandwidth
On-Going and Future Work
•
•
•
•
•
•
•
Message delivery guarantees
Decentralized ownership
Trust
Need for specialized programming languages
Resource analysis
Automated optimized application deployment
Scalability assessment
Descargar

DASADA Phase II Thoughts and Ideas