+ overview of embedded systems & embedded software engineering csci 589: software engineering...

+

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


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


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


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.


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


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

+

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

+ overview of embedded systems & embedded software engineering csci 589: software engineering...

Documents