Overview of Embedded Software Research at USC

1
Overview of EmbeddedSoftware Research at USC

• CSCI 589 Software Engineering for
  Embedded Systems
• September 8, 2003

2
Architectural Abstraction
3
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

4
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

5
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 invocationvia connectors
• Substrate independence
• Concurrency
• Distribution
• Heterogeneity

User Repository
Main Window
Login Dialog
Graphics Toolkit
6
C2 Connectors

• Enable key C2 properties
• Implement message passing policies

• Support message registration and filtering
• Polymorphic interfaces

7
Programming-in-the-Small-and-Many
Prism
8
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

9
Prism Architectural Style Framework Prism-SF

• Originally inspired by C2
• Instantiable into different styles
• Different types of interaction
• Asymmetric (master-slave)
• Symmetric (peer-to-peer)
• Architectural self-awareness
• Application-level components
• Meta-level components
• Different message types
• Application data
• Component content
• Architectural model
• Subscription messages

A
Requests
Notifications
C
B
Peer
D
10
Designing Prism Architectureswith Prism-SF
11
Prism Connectors

• All Prism connectors are able to exchange data,
  code, and architectural models
• Communication paradigms
• Symmetric vs. asymmetric
• Synchronous vs. asynchronous
• Different connector types
• Basic
• Border
• Secure
• Multi-versioning

12
Basic Connectors

• Synchronous and asynchronous interaction
• Message routing policies
• Unicast
• Multicast
• Broadcast
• Support for real-time constraints
• Delivery guarantees

13
Border Connectors

• Spanning contexts
• Address spaces
• Processes
• Machines
• Marshalling and unmarshalling of information
• XML encoding
• Wireless interaction
• Network link monitoring
• Mechanisms
• CORBA, RMI, Sockets, ILU, Q, Polylith

14
Secure Connectors

• Useful in connector-to-connector interaction
• Reusable security module
• Multiple such modules would allow altering
  security policy on the fly
• Open issue
• Mismatched security policies by interacting
  connectors

15
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

16
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

17
Implementing Prism-Style Architectures Prism-MW

• 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

18
Prism-MW 1.x Design (deprecated)
19
Prism-MW 2.0 Design (current)
20
Internal Working of Prism-MW
Thread Pool
Component B
Component
A
handleRequest
Connector
C
X
R
R
N
N
R
R
1
1
2
2
3
send Request
Component
D
21
Prism-MW Operational Details

• Sizeunder 5KB at system start-up
• Performance300MHz PentiumII Java KVM
  framework two components one connector one
  thread one million messages___________________
  __________________________________________________
  _________________________________ 13 seconds
• Adjustable threading
• Adjustable scheduling

22
Prism-MW 1.xAPI (deprecated)
23
Prism-MW 2.0 API (current)
24
Using Prism-MW 2.0
Component D sends an event Event e new Event
(Event_D) e.addParameter("param_1", p1) send
(e)
Send (e)
// establish the interconnections arch.weld(a,
new Port (PrismConstanst.REPLY,a), conn, new
Port(PrismConstants.REQUEST, conn)) arch.weld(b,
new Port (PrismConstants.REPLY, b), conn, new
Port (PrismConstants.REQUEST, conn)) arch.weld(c
onn, new Port (PrismConstants.REPLY, conn), gui,
new Port (PrismConstants.REQUEST, gui))

25
Example Prism Application
26
Another View of the Application
M
27
Deployment Support Prism-DE

• Leverages ComponentContent messages
• Assumes preloading a skeleton configuration on
  each device
• Monitors system connectivity
• Implemented as an extension to MS Visio (COTS)

add(DataRepository source PC)
PC weld(TopBorderConnector,C_IPAQAvailableTroops)
iPAQ peerWeld(G_AvailableTroops,SideBorderConnect
or) Palm-1
28
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)
• PCs 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)

29
Support for Disconnected Operation

• Goal Maximize availability of a distributed
  system in face of connectivity losses
• Availability ratio of the volume of successfully
  completed interactions to the total volume of
  attempted interactions
• Performed via
• Monitoring, to gather the necessary data
• Estimating the redeployment architecture
• Effecting the redeployment

30
Factors that Influence Redeployment

• Frequencies of interaction among software
  components
• Sizes of communication events exchanged
• Memory requirements for software components
• Reliability of connectivity among hardware hosts
• Network bandwidth between hosts
• Available memory on each host
• Other factors (CPU, battery power,
  available/required SW)

31
Redeployment Problem

• Find a deployment architecture that maximizes the
  availability of a given software system for the
  given target hardware environment
• Problem is exponentially complex
• (num_hosts)num_comps
• Can we find good approximations?

32
On-Going and Future Work

• Message delivery guarantees
• Decentralized ownership
• Trust
• Need for specialized programming languages
• Resource analysis
• Automated optimized application deployment