Embed Size (px)
+
Overview of Embedded Systems& Embedded Software Engineering
CSCI 589:Software Engineering for Embedded Systems
+Software Qualities
Qualities (a.k.a. “ilities”) are goals in the practice of software engineering
External vs. Internal qualities Product vs. Process qualities
+External vs. Internal Qualities
External qualities are visible to the user reliability, efficiency, usability
Internal qualities are the concern of developers they help developers achieve external qualities verifiability, maintainability, extensibility, evolvability,
adaptability
+Product vs. Process Qualities
Product qualities concern the developed artifacts maintainability, understandability, performance
Process qualities deal with the development activity products are developed through process maintainability, productivity, timeliness
+Some Software Qualities
Correctness ideal quality established w.r.t. the requirements specification absolute
Reliability statistical property probability that software will operate as expected
over a given period of time relative
+Some Software Qualities (cont.)
Robustness “reasonable” behavior in unforeseen
circumstances subjective a specified requirement is an issue of correctness;
an unspecified requirement is an issue of robustness
Usability ability of end-users to easily use software extremely subjective
+Some Software Qualities (cont.)
Understandability ability of developers to easily understand produced
artifacts internal product quality subjective
Verifiability ease of establishing desired properties performed by formal analysis or testing internal quality
+Some Software Qualities (cont.)
Performance equated with efficiency assessable by measurement, analysis, and
simulation
Evolvability ability to add or modify functionality addresses adaptive and perfective maintenance problem: evolution of implementation is too easy evolution should start at requirements or design
+Some Software Qualities (cont.)
Reusability ability to construct new software from existing pieces must be planned for occurs at all levels: from people to process, from
requirements to codeInteroperability
ability of software (sub)systems to cooperate with others
easily integratable into larger systems common techniques include APIs, plug-in protocols,
etc.
+Some Software Qualities (cont.)
Scalability ability of a software system to grow in size while
maintaining its properties and qualities assumes maintainability and evolvability goal of component-based development
+Some Software Qualities (cont.)
Heterogeneity ability to compose a system from pieces developed in
multiple programming languages, on multiple platforms, by multiple developers, etc.
necessitated by reuse goal of component-based development
Portability ability to execute in new environments with minimal effort may be planned for by isolating environment-dependent
components necessitated by the emergence of highly-distributed systems
(e.g., the Internet) an aspect of heterogeneity
+Software Process Qualities
Process is reliable if it consistently leads to high-quality products
Process is robust if it can accommodate unanticipated changes in tools and environments
Process performance is productivityProcess is evolvable if it can accommodate new
management and organizational techniquesProcess is reusable if it can be applied across
projects and organizations
+Assessing Software Qualities
Qualities must be measurable Measurement requires that qualities be precisely defined Improvement requires accurate measurement Currently most qualities are informally defined and are
difficult to assess
+Software Engineering “Axioms”
Adding developers to a project will likely result in further delays and accumulated costs
Basic tension of software engineering better, cheaper, faster — pick any two functionality, scalability, performance — pick any two
The longer a fault exists in software the more costly it is to detect and correct the less likely it is to be properly corrected
Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design detecting the causes of those faults early may reduce their
resulting costs by a factor of 100 or more
+
Embedded Software
Interaction with physical world
Executes on devices, not “computers”
Written by engineers who are domain experts
Current methods offered by computer scientists are not always satisfactory
Complexity and size of embedded software are growing rapidly severe constraints remain
+Properties of Embedded Software Timeliness
speed up in software not hardware
Concurrency Predictability and adaptability
Liveness Non-terminating
Interfaces Processes not procedures
Heterogeneity Reactivity
Continuously changing to adapt to changing environment
+What Is an Embedded System?
A computer whose end function is not to be a computer Automobiles
ABS “radio” Engine
Digital cameras Household appliances TVs
A combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function.
+Put Another Way
An embedded system is a specialized computer system that is usually integrated as part of a larger system consists of a combination of hardware and software
components forms a computational engine performs a specific function constrained in its application reactive time-constrained
+ Modern Embedded Systems
Novel computing platforms Smart phones Mobile robots Motes Sensors
Novel usage scenarios Search-and-rescue Environment exploration Traffic management Medicine / Assisted living Wireless sensor nets Mobile grids
Novel SE challenges Distribution Decentralization Mobility Heterogeneity Resource constraints Context awareness Real-time requirements
+Typical Embedded System
+Reactive Systems
Respond to the environment via sensors
Control the environment using actuators
Must achieve performance consistent with the environment periodic vs. aperiodic eventse
+Embedded Systems Functions
Monitor and react to environment
Control the environment
Process information
Application-specific behavior
Optimization
Resource-economy
Real-time performance
Multi-rate performance
+Interfacing with the Environment
+Car Window Lift Aided by Sensors
+Car Window Lift – Software Design
+Car Front Light Mgmt System
+More Cars
+
+Real-Time Computing
+Car Shift Control System - HRTC
+Traditional vs. RT Systems
System capacity High throughput
vs. Schedulability and ability to meet deadlines
Responsiveness Fast average
vs. Ensured worst-case latency and response time
Overload Fairness to all
vs. Stability, priority to important tasks
+RT Events
Asynchronous unpredictable
Synchronous predictable and precisely regular
Isochronous regular within a time window
+RT System Design Challenges
Response time factors Suitability of architecture Processing element power Communication speed Adequacy of scheduling system
Failure recovery causes processor failures board failures link failures invalid behavior of external environment interconnectivity failure
+Building an Embedded System
Desktop
Embedded
+Ferrari’s Build Process
+Embedded vs. Desktop Systems
Energy efficiency
Custom power requirements
Security
Reliability
Environment extremes
Efficient UI
+Hardware Abstraction Layer (HAL)
+Embedded System Development
+ Challenges for SE
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
+ From Design to Implementation
Architectures provide high-level concepts Components, connectors, ports, events, configurations
Programming languages provide low-level constructs Variables, arrays, pointers, procedures, objects
Bridging the two often is an art-form Middleware can help “split the difference”
Existing middleware technologies Support some architectural concepts (e.g., components, events) but not others (e.g., connectors, configurations) Impose particular architectural styles
End result architectural erosion Architecture does not match the implementation
+ How do we get from
+ How do we get from
+
to
How do we get from
+
to
?
to
How do we get from
+Architectural Middleware
Native support for architectural concepts as middleware constructs
System design support via an accompanying ADL
Quality assurance via analysis and simulation of architectural models
Round-trip development from architecture to implementation and back
Automated transformation of architectural models to implementations
+ Prism-MW
An architectural middleware for ES
Supports architecture-based software development Implementation of a software system in terms of
its architectural elements
Efficient
Scalable
Flexible and Extensible Allows us to cope with heterogeneity
Supports arbitrary architectural styles
+ Architectural Middleware Architecture
+ Prism-MW Design
+
Architecture – Ar1
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture (”Ar1");
// create componentsComponent a = new CompA ("A");Component b = new CompB ("B");Component c = new CompC (“C");// create connectorsConnector d = new Connector(“D");// add components and connectors arch.addComponent(a);arch.addComponent(b);arch.addComponent(c);arch.addConnector(d);// establish the interconnectionsarch.attach(a, d);arch.attach(b, d);arch.attach(d, c);}
}
Using Prism-MW
Comp BComp A
Comp C
Connector D
Connector D
Comp A Comp B Comp C
+
Architecture - DEMO
Component B handles the event and sends a response
public void handle(Event e){
if (e.equals("Event_C")) {... Event e1= new Event("RSP_to_C“, REPLY);e1.addParameter("response", resp);send(e1);}...
}
Send
(e1)
Using Prism-MW
Component C sends an event
Event e = new Event ("Event_C“, REQUEST);e.addParameter("param_1", p1);send (e);
Send
(e)
Comp BComp A
Comp C
Connector D
+
Connector D
Event Dispatching
Comp BComp A
Comp C
E1
E2
E3
E4
E5
send
Eve
ntha
ndle
Eve
nt
Thread Pool
E
X EX
Scaffold
Topology-based routing Easy redeployment and redistribution of
components onto different hardware configurations
2E
+ Prism-MW Performance
Efficiency
• 1750 SLOC
• 4600 B for the core
• 160 B per component
• 240 B per connector
• 70 B per weld
• 160 B per event
• 240 B per event parameter
100 001 components100 000 connectors
Total event roundtrip time 2.7 sec
…
Scalability
• Numbers of devices, threads and eventsnot limited by Prism-MW
• Numbers of components and connectors
available_memory – middleware_size
average_element_size
+Prism-MW Benchmarks on a
PC
+ External Adoption
Troops Deployment SimulationUS Army
MIDASBosch Research and Technology Center
+MIDAS Architecture
