embedded systems unsuitable for object orientation maarten boasson quaerendo invenietis b.v....
Post on 21-Dec-2015
217 Views
Preview:
TRANSCRIPT
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– -
Architecture requirements
• Minimize design complexity
– Generic solutions where possible– Support where no generic solution exists
• fault-tolerance
– Enable re-use of components– Incremental development
Architecture requirements
• 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
Architecture requirements
• 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
Architecture requirements
• 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
Architecture requirements
• 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
Architecture requirements
• 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...
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...
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...
Splice: A reactive systems’ architecture
Data is dynamically forwarded toall subscribing processesList of subscriptions is dynamicallymailtained
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
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;}
Splice: A reactive systems’ architecture
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Content-based subscription throughrelational views
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
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
Splice: A reactive systems’ architecture
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Persistent data remains availablefor later access
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Persistent data remains availablefor later access
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Processes may join or leavethe network at any time
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
QoS is attributed to data (staticallyor dynamically)
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
- persistency- delivery- priority
Splice: A reactive systems’ architecture
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]
Splice: A reactive systems’ architecture
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...
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
Splice: A reactive systems’ architecture
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
Splice: A reactive systems’ architecture
Splice: A reactive systems’ architecture
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
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Semi-active 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...
Splice: A reactive systems’ architecture
Semi-active 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...
Splice: A reactive systems’ architecture
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
LAN
WAN
Splice: A reactive systems’ architecture
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
simulation data
operational data
Splice: A reactive systems’ architecture
Orthogonal scoping mechanism
• Scoping without interfering with type-safety• Can safely be imposed by the environment• Dynamically changing scopes possible
Splice: A reactive systems’ architecture
Dynamic scopes
Built-in capabilities:- P/S data distribution- relational data access- data persistence- dynamic (re-) configuration- quality of service- fault-tolerance- network partitioning- security...
Splice: A reactive systems’ architecture
Work in progress
Splice: A reactive systems’ architecture
• 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
real-timeinformation
broker
application
cache
real-timeinformation
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
Coordination language
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)
Coordination language
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]
Coordination language
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) )
) *
Coordination language
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
Coordination language
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
top related