embedded systems unsuitable for object orientation

Embedded Systems Unsuitable for Object Orientation

Maarten Boasson

Quaerendo Invenietis b.v.

Universiteit van Amsterdam

Alternative titles

Object Orientation unsuitable for RS

Object Orientation harmful for RS

Monoculture detrimental to RS design

Fanaticism stifling progress in software

There is nothing new ...

Reactive system evolution

• Current systems:

– Very little support for decision making

– Inflexible

– Always wrong

– Very expensive

• Future systems

– All of the above inverted

functionality

cost

time

Object Orientationcost

time

functionality

ISO9000, CMM

functionality

cots

time

The engineering problem

connectivityconnectivity

timelinesstimeliness

availabilityavailabilityevolvabilityevolvability

performanceperformance

securitysecurity

The Idea

• Design principles:– Minimize dependencies between components

– Share stable properties

• Focus on:– Autonomous component behavior

– Shared information model

• Solidify knowledge and practices in terms of:– System architecture

– Supporting middleware

Architecture

• Reduces the design freedom

in exchange for

• Guaranteed system properties

Architecture requirements

• Rich enough to support applications

– Functionality– Performance– Extensibility– Availability– Security– -


• Minimize design complexity

– Generic solutions where possible– Support where no generic solution exists

• fault-tolerance

– Enable re-use of components– Incremental development


• High performance

– must transfer data as fast as possible• programs must be delayed as little as possible

– must be able to handle required volume of data– must not introduce many layers of abstraction

• each layer introduces delays and overheadhowever: use abstraction where useful


• Extensibility and growth potential

– must manage relations between applications• applications must to be invariants under extensions

– must provide support for system management• extending a system means new programs/processes

that need to be monitored and controlled


• System availability

– must either support hot standby• if interrupted processing not acceptable

– or must support cold standbyand/or dynamic reconfiguration

• choice depends on temporal properties, system configuration and fault models

– must manage critical data• starting programs need to operate in the right context


• Design complexity

– Component reuse:no built-in dependencies on other components

• dependencies must be determined dynamically

– Separate development of components• no built-in dependencies on other components

• must be able to fully specify components


• Amenable to formal reasoning

– Mathematical description of properties• both of infrastructure and of applications

– Transformations from system requirements to software implementation

– Separation of concerns• function and coordination separated

Object Orientation makes life difficult

• Packaging of methods and data

• Method invocation strong coupling between objects

• Attempts at rectification have failed– CORBA event service– data distribution service (in progress)

• OO is essentially analysis oriented

Shared Data is architecture well suited

• allows maximum independence between components(only data in common)

• allows secure systems to be built(control of all data access)

• allows standard solution to many system problems (distribution, communication, replication, extension)

• "open": anybody can develop components for systems

• supports multi-paradigm programming (including OO)

• avoids unnecessary complexity

• enables formal reasoning

Towards a solution

True sharing of data is impractical

“The right data at the right place at the right time”

Remember:No single point of failure

High performance

Extensible

….

Splice: A reactive systems’ architecture

Decoupling in space and time

Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...


Data is dynamically forwarded toall subscribing processesList of subscriptions is dynamicallymailtained


Data Definition

• Processes subscribe to subjects

• Each subject has an associated data type:– record structure with named, typed fields

– key fields for unique identification

• Example:

struct TrackPosition { key int trackNumber; Point3D position; Time timestamp;}

struct TrackIdentity { key int trackNumber; Identity identity; Time timestamp;}

Content-based subscription throughrelational views



Content-based Subscription

• Data filtering, e.g. in SQL:

• Aggregation and projection, e.g. in SQL:

select * from TrackPositionwhere position.range < 10000

select position from TrackPosition, TrackIdentitywhere TrackPosition.trackNumber = TrackIdentity.trackNumber and position.range < 10000 and identity = hostile

Typical Process BehaviorAnnounce publications

Define views

Subscribe to views

Define queries

Set query parameters

Select input data Wait for input data

Process data

Publish output data

Persistent data remains availablefor later access



Processes may join or leavethe network at any time



QoS is attributed to data (staticallyor dynamically)


- persistency- delivery- priority


Data Persistency

• Volatile data– no copies outside process space

– typically measurement related data

• Semi-persistent data– copies are kept on more than one host

– outlives process

– typically state related data

• Persistent data– same as semi-persistent data, but additionally stored on disk

– outlives system

– typically configuration data

Data Delivery

• Various options:– no guarantees [0,)

– at least once [1, )

– at most once [0,1]

– exactly once [1,1]


Passive process replication


Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...Passive process replication



Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...Semi-active process replication



Semi-active process replication


LAN

WAN



simulation data

operational data


Orthogonal scoping mechanism

• Scoping without interfering with type-safety• Can safely be imposed by the environment• Dynamically changing scopes possible


Dynamic scopes



Work in progress


• Mono-culture?– Yes, at the level of the architecture– No, at the level of individual application-level

components

• Object-Oriented?– Maybe, from the perspective of the middleware– No, at the level of the application

Realization

application

Networking (UDP/IP)

cache

real-timeinformation

broker

application

cache


broker

application

cache


broker

Connectivity

herald i herald j

appl appl

multicast / broadcast

shared-data space

Initial situation

Connectivity

herald i herald j

appl appl

publish() subscribe(,cache)

cache

shared-data space

need for data of sort “”availability of data of sort “”

Declaration of intent

Connectivity

herald i herald j

appl appl

publish() subscribe(,cache)

j shared-data space

need for data of sort “”availability of data of sort “”

cache

Declaration of intent

ConnectivityWrite operation

herald i herald j

appl appl

write(,v)

j

forward data

+v

shared-data spacetimestamp

Connectivity

appl appl

X = read(,q)

: j, k

V

shared-data space

herald i herald j

Read operation

Connectivity

write(,v)

, QoSj

forward data using specified QoS

<,v0,t0>, <,v1 ,t1 >, ..., <,vn ,tn >

t < t0 + timeoutn = buffersize

herald i

Write operation in detail

Fault tolerance

all state data

statedataPC

platform i platform k

statedata

all state data

Fault tolerance

all state data

statedata

P new C

platform i platform kplatform i

statedata

Fault tolerance

all state data

statedata

P new C

platform i platform kplatform iplatform i

statedata

Splice

• Deceptively simple, yet powerful– major shift of application complexity to middleware

– has demonstrated to greatly simplify system design

– radically changed the ratio between design and integration effortfrom 50/50 90/10

• Integration oriented– components

– legacy systems

– incremental deployment

– interoperability

– different operational modes

Splice

• Highly adaptive– history proof

– component re-use

– robust

– scalable

• Paradigm shift– simple concept, thus small learning effort

– bridges the gap between design and implementation

Splice

• Technologies used in Splice finally becoming mainstream– peer-to-peer communication

– push technology

– process autonomy

– data caching

• Concept has not changed last 25 years and needs no change ...– language independent

(imperative [C, Ada, Java, C#, …], functional, logic, …)

– HW & OS independent

Some statistics

• “Air-defense” system: Psplice / P corba = 50

• Reuse: about 85% of new system is old code

• New German frigateintegration of ~1000 software components (all new): 1st time right

• Cars example: one weekend / one person

• Size– per system: 64 k

(includes nameservers , persistence, standby process management)

– per node: 84 k

– per application process: 424 k + cache(excluding cached data)

Developments

• Mathematical foundation– formal semantics

– process algebra

allows reasoning about program behaviour

– fully transparent process replication

• Basis for research & development projects– distributed decision making (intelligent agents, NCW)

– engineering support (methods, tools)

– implementation of monotonic dataspace

– descriptive metadata (improved support for interoperability)

Coordination language

P ::= | a!v | a(v) | R.P | P||P | P+P | P*R ::= {a?x*}:q

empty processa!v write tuple (a,v) to dataspace

this action is non-blocking

a(v) remove arbitray many tuples (a,w): (a,w) (a,v)this action is non-blocking

{a1?x1, ..., an?xn}:q . P search sets {vi1, ..., vin}, such thatq[vi1/x1,...vin/xn] holds

this action is blockingP||Q parallel compositionP + Q non-deterministic (inclusive) choiceP* infinite (possibly parallel) repetition


commutativity: P || Q = Q || PP + Q = Q + P

associativity: (P || Q) || R = P || (Q || R)(P + Q) + R = P + (Q + R)

idempotency: P || P = PP + P = P

distributivity: a?x.P + a?x.Q = a?x.(P + Q)P || (Q + R) = (P||Q) + (P||R)


NOT given is: a?x . P || a?x . Q = a?x . (P||Q)

consider e.g.

a?x . b!v || a?x . c!w || a(u), with S = { <a,u> }

then this may result in S = { <b,v> } and no further step is possible

but in

a?x . (b!v || c!w) || a(u)

that can never occur

<P||P*,S> <P’,S’><P*,S> <P’,S’>

<P,S> <P’,S’><P+Q,S> <P’,S’><P+Q,S> <P’+Q,S’>

<P,S> <P’,S’><P||Q,S> <P’||Q,S’>

<P,S> <P’,S> <P,S> <P’’,S><P,S> <P’ + P’’,S>

Coordination language<a!v,S> <,S {(a,v)}><a (v),S V> < ,S> if V. (a,v)

<a?x:q. P,S> <P[v/x],S> if (a,v) S q[v/x]


A simple example:

A sensor generates position measurements (plots).The tracking problem is to correlate them.

tracker: ( {plot?p, track?t } : [correlates(p,t)] .

( track!(p,t) || plot(p) )

) *


sensor_track: (Source, Id, Vector, Int)system_track: (Id, Vector, Int)table: ((Source, Id) Int, Int)search: ({Int}, Id, Int)

main = join * || find *join = { table?(,k), sensor?(s,i,x,k)}.(update(,s,i,x,k) || table!([(s,i):=k],k+1))update(,s,i,x,k) =

system_track?(j,y,k’): decorrelates(x,y) k’ . system_track!(j,F(x,y),k)+ system_track?(j,y,k’): decorrelates(x,y) k’ . search!(ran()\{},0,k)+k’= . search!(ran()\{},0,k)

where k’=(s,i)

find = {search?(K,m,k),sensor_track?(s,i,x,k)} . let k’ = min K in K= . system_track!(m+1,x,k)+ system_track?(j,y,k’):correlates(x,y) K . system_track!(j,F(x,y),k)+ system_track?(j,y,k’): correlates(x,y) K . search!(K\{k’}, max(j,m),k)

correlate

decorrelate


main = index* || (update + decorrelate + new_sensor_track)* || (new_system_track + associate + find)*main = index* || update * || decorrelate* || new_sensor_track* || new_system_track* || associate* || find*

index = {table?(,k),sensor_track(s,i,x,k)} . table!((s,i):=k,k+1)update = {table?( ,k),sensor_track?(s,i,x,k),system_track(j,y,k’)}: decorrelates(x,y) k .

system_track!(j,F(x,y),k)where k’ = (s,i)

decorrelate = {table?( ,k),sensor_track(s,i,x,k),system_track(j,y,k’)}: decorrelates(x,y) k .search!(ran()\{},0,k)

where k’= (s,i)new_sensor_track = {table?( ,k),sensor_track(s,i,x,k)}: (s,i)= . search(ran()\{},0,k)new_system_track = {search?(K,m,k),sensor_track(s,i,x,k)}:K= . system_track!(m+1,x,k)associate = {search?(K,m,k),sensor_track?(s,i,x,k),system_track?(j,y,k’)}:correlates(x,y) K .

system_track!(j,F(x,y),k)where k’=min K

find = {search?(K,m,k),sensor_track?(s,i,x,k),system_track?(j,y,k’)}: correlates(x,y) K .search!(K\{k’},max(j,m),k)

where k’=min K

embedded systems unsuitable for object orientation

Documents

system configuration

system requirements

system managementextending

system problems distribution

little support

embedded systems unsuitable

analysis orientedshared

secure systems