Evolving Systems

EvolvingSystemsbyIgorSchagaev

!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!itacs ltd, Registered Office 157 Shephall View, Stevenage, Hertfordshire, SG1 1RR, UK

email [email protected], MT +44-7506-9831-70, Incorporated in Cardiff Wales No. 5865985 Bank: Lloyds TSB Branch: 30-95-72 Montpelier Cheltenham Account Name: IT-ACS Ltd, Account Number: 02399207

IT-ACS Ltd

www.it-acs.co.uk,[email protected]

EvolvingSystems:FundamentalReasoningfromamoebatohumandesigns

Poten<alcustomers:

Why recoverability? One example!

Periodic impacts

Recovery Recovery Recovery

Recovery after impact in “natural world” becomes faster, provided an element has sufficient redundancy and evolute i.e. learn from each impact

4Saturday, 30 July 2011

Thisistrueforamoeba...

EvolvingSystems:FundamentalReasoningfromAmoebatohumanWhy recoverability? One example!

Periodic impacts

Recovery Recovery Recovery

Recovery after impact in “natural world” becomes faster, provided an element has sufficient redundancy and evolute i.e. learn from each impact

4Saturday, 30 July 2011

This is true for amoeba…NOT FOR OUR

DESIGNS !!!!

§  Casestudies§  Proper7esrequired(fordesign,development,analysis,lifecycle)§  Models,Methods,Toolsrequired,orapplicable§  GainachievableWhatfor?:-  thereisaneedtodetectparadigm(scien9fic,technological.moral,social)shi>sas

soonaspossible,-  todefineareasofresearchwithhighefficiencyandoutcomeanddecliningonesBothmustbedoneASAP,AGAPandALAP(assoonandasglobalandlocalaspossible)Importance?See“TheChoiceoftechnology”VLeon9eff

EvolvingSystems:theessen<alsteps

Poten<alcustomers:

§  Humanrace§  Industries§  Researchers§  Governments?Notsure…

§  Finetuningofhumanprogress§  RigorofparadigmshiJfornewtechnologies§  Newapplica7ondomaindiscoveries§  Cross-domaindiscoveries

Reasoning:

EvolvingSystemsPlan Evolvingsystemscience

Aerospace

Monitorofac7vesystemsafety

Prototypeofac7vesystemcontrol

MethodofAc7veSystemControl

Ac7veblackbox

Real-7memaintenance

EvolvingDelivery

EvolvingAssessmentEvolving

KnowledgeAggrega7on

Educa7onLife?

Defini7on(s)?

Nature

Repeatability

Redundancy

Evolvement

Recoverability

Economics

Projectlifecyclemonitor

Analy7c

Feedbackmodels:

Full,limited

Simula7on

lifecycleeconometrics

Methods

Applica7on

SystemsoJware

Interac7onfabric

Computerscience

DualstringRecoverable

datastructures

Searching&recoveryalgorithmsLanguage

Run-7mesystem

FTsemaphoresNewcontroloperators

Syndrome

PREmonitors

Hardware Ac7vezone Passivezone

Systemmemory

Usermemory

LU AU

T-logic

Math

Control-Data--Predicatemodel Graph-Logic

Model

DependencyMatrixesModel

EvolvingSystems.Goodexamplesofourignorance:Aerospace

Evolving models in aerospace: active system control

One of the most critical area of pursuing evolvement through conceptual design up to everyday application is aerospace, it includes aviation and space and human lives well as colossal investment of labor, money technologies.

One example of Shuttle disaster (wired.com) is enough to figure it out: Figure 22.

source : http://www.wired.com/2012/05/shuttle-with-aft-cargo-carrier-1982/

Figure 22 Shuttle case

What can science do in principle and also our evolving concept in applications like aerospace and aviation? As an example, let’s also dig a little deeper, checking the timing in this accident attempting to extract what was theoretically wrong in design and how evolving principle should be applied, Figure 23.

Flight data were recorded on the ground and … stored for future analysis.

Even with on-ground recording plenty of time was wasted after leak appearance and registration. In the Challenger systems, nothing was done to save the situation even though all the necessary data about the state of the spacecraft were available in real time. This is particularly sad as the reconfigurability (see Figure 22), on which the Challenger design is based, could have been

�38

!

Solid-state booster,

separation 120 sec after launch

!External tank,

jettisoned, 480 sec after

launch

!Solid-state booster,

separation 120 sec after

launch

!

Winged orbiter

!Orbiting

Manoeuvring System

(Two engines)!

EvolvingSystems:Goodexamplesofourignorance:Aerospace-1A

§  Government§  Industries§  InvestmentFunds

Timing:

Leak

Flight data recording(on ground) Leak visual manifestation

Accident

72 seconds

Time for possible emergency reconfiguration and recovery of

Challenger to safe state

FLIGHT(blast off)

Flight able to continue in a safe state after recovery operation

10 seconds

Even available system reconfigurability was not applied when required.

EvolvingSystems:Goodexampleofourignorance:Econometrics&SE

Projectphasedependenciesbecamecomplex,amountofdataaboutprojectrequiredbigdataini7a7ves,datacentersand…andweinvent…theAgiletechnology?(39Millionslinks!)

ba c d

ba c d

this

Duetoevolvingpropertyofaliveobjectbecomesthat:

Projectlifecycle:

Quan9ta9veproblemcausedqualita'vesolu7ons?30+proper7es,mutuallyexclusiveanduncertaincanmakeaprojectefficient?Whomarewekidding?

NB.”Freshair”iss9llavailable–seeWorldComp15“Quan<ta<veSoHwareEngineering”

Andactuallythat–whenphasesrepeated/evolvedinternallyandproject=lowlookslikethat:

EvolvingSystems.Goodexamplesofourignorance:HighEduca<on

Handlingthisinreal7me–upgradingeveryyear?

hbps://www.academia.edu/7114207/Essen7al_Knowledge_Aggrega7on_Delivery_and_Assessment

EvolvingSystems.Goodexamplesofourignorance:HighEduca<on

Brainmodelingforthepurposeofeduca7on?Improvement?Efficientuse?NeitherECnorUS“superbrain”programshavenothingincommontothispicture

hbps://www.academia.edu/7114207/Essen7al_Knowledge_Aggrega7on_Delivery_and_Assessment

§  Changeinsize,power,reducingorgainingnewproper7esandfunc7ons§  Costdependsonamountofresources(redundancies)spenttoimplementchange§  Redundancycanbe“natural”,i.e.exis7nginthesystemforthereasonwearenot

awareof,RNand“introduced”redundancyRI§  Foroursystems(ICT)RIcanbeof3typesStructural,Time,Informa9on:RI(S,T,I)

EvolvingSystemsatLarge-SystemLevel

Redundancy types were defined in [SK14], [CS15], R3 paper [MS13]. Here we mention that redundancy types are structural, Informational and time.

How all this jazz about redundancy types and algorithms can be used to achieve a property relates to evolving systems? Well, referring to Figure 1 one might find that speed of adjustment for amoeba is increasing.

Figure 4 illustrates how evolving organisms or systems might interact with the external world and react on external impact or internal change. When “training” took place and patterns to react are in place then an organism (and, similarly, object of our design) should be capable of performing a recovery or, even reconfigure if interaction has resulted in severe loss of internal resources available.

Resources in the form or redundancy and “algorithm” of its application enables reconfigurability; such reconfigurability might be involved in implementation of recoverability. Recoverability itself needs resources and might use different redundancy types as well. Therefore, a competition between execution of steps of an algorithm for various types of resources and/or redundancies is very likely to occur and should be addressed while we are trying to make a system efficient.

Organisation of resources and redundancy (elements and links as well as their functions) define and support the flexibility of an object or species. The organisation and structure of resources defines system ability to execute detection and recovery. The more flexibility an object has in terms of use of resources the higher “degree of freedom” and stronger evolving ability of a system.

Figure 4 Evolving process vs. redundancy

�9

Evolving#systems#implementa7on#by#nature#or#by#us##includes:#

reconfigurability''resources'

abili*es'to'use:''flexibility'

degree'of''freedom''

amount'and''organiza*on'of''redundancy'

abili*es'to'implement'''p.a'and'p.b'H'i.e.'level#of#evolvability#

NB1.#When'top'boxes'are'in'ac*on'and'each'itera*on'of'system'applica*on'is'improving'then'process'of'evolvement'exists.'

NB2.#Good'evolving'process'is'“smooth”'in'terms'of'performanceH,'reliabilityH'and'energyH'efficiency.''

enable#

define#

a.'detec*on' b.'recovery'needs# includes#

sensing'

memory'crea*on'

paWern'of'sensing'H'recogni*on'of'impact'

described#as###define#

§  Naturalsystemsareevolving;howtodescribeevolvability:

§  sta7cally(whenwedesign–atproject/designphase)§  dynamically(duringopera7on/func7oning–whenproper7esarechanging)

§  Howourtheories/modelsmustbemodifiedtoreflect

§  Thereal,physical,chemicalproper7es,notmathmodelsweuse(causeweknow)§  Canwemodifytheoryaccordinglytherealneednotourconvenience…

EvolvingSystemsatLarge:Theneedofnewtheoryandmethods

Poten<alstar<ngpoints:

§  Categories§  Graphtheory§  Markovprocesses§  Controltheory§  Dependencystudies(Aristotle,DaVinci)

§  RedundancyTheory§  GraphLogicModel§  DependencyMatrixModel§  Control-,Data-,Predicate-models

Reasoning:

EvolvingSystemsatmedium–Models:Redundancy&GLM

Real-<meGLM:

Design<me–DependencyMatrix(DM):

Therefore, the market segmentation of computer systems for information computer technologies (ICT) will be reduced dramatically, merging various domains such as embedded, desktop, autonomous, safety critical and game systems.

To implement consistently performance requirements during design an algorithm - sequence of steps - required, Figure 8. Similar sequence of actions is required for implementation of energy-efficient systems - all requirements are here based on reconfigurability [SCT15] recoverability and implementation of sequence of steps - all these efforts might be considered as part of evolving process.

Figure 7. Generalised algorithm of fault tolerance as a part of an evolving property

Regrettably, performance, reliability, and energy saving as algorithms here briefly presented, are simplifications. All these algorithmic implementations are not, in fact, simple sequences. They are most likely to follow a pattern with multiple feedbacks between phases/steps, as explained in

�20

Redundancy: Hardware (HW), Software (SW)Redundancy: Hardware (HW), Software (SW)Redundancy: Hardware (HW), Software (SW)Redundancy: Hardware (HW), Software (SW)Redundancy: Hardware (HW), Software (SW)Redundancy: Hardware (HW), Software (SW)

HW(i) HW(s) HW(t) SW(i) SW(s) SW(t)

A

C

D

E

F

B

G

A Prove HW integrity

C If fault is permanent, then

D Locate faulty element of HW

E Reconfigure HW

F Prove SW integrity, else

G Determine correct SW state

H Continue (recover) from SW

B Determine type of HW fault

NB. Redundancy types are in our brain, hardware and software are in real world

§  AnynewpropertyofasystemisasequenceofstepsA-G…

§  Redundanciesmightbeuseda-labestfit4astep

GLM in brief

GLM stands for Graph Logic Model and is used to describe mutual dependency of various kinds. It has been successfully applied in real world projects, including active conditional control systems, active safety monitoring systems. Its descriptive power is greater than overpowers of Markov and Bellman models and similar techniques.

Figure 5 A graph logic model of interactions between nodes

Accordingly GLM, on leaving one state, say “a” on Figure 5, we might describe our leaving conditions using basic logic operators {AND, OR, XOR} attached to a leaving end of the links between “a” and neighbours. We introduce (Figure 6) a link as a core of a model with leaving and arriving conditions combined into an arbitrary function f(x). This defines dependencies between a and b nodes.

Figure 6 Semantics and logic of link

Various options are possible to characterise the leaving conditions toward various neighbours. The modality of leaving might be expressed using OR on each out-going link. In turn, a broadcasting mode to all neighbours through all-out-going links is described using AND operator on each leaving end of edge; finally, picking just one or select concrete neighbours is possible using operator XOR.

�13

NOT IEEE TRANSACTIONS OR JOURNAL, THIS IS ITACS OFFICIAL PUBLICATION 1

Control operators vs Graph Logic Model

Igor Schagaev

Abstract—Simple paradigm to unite control operators for programming languages into one scheme using graph-logic representation of relations between agents (or elements of interaction) assuming independence of behavior for each element is presented. Shown that power of this structure exceed known models of description of behavior for concurrence and parallelism. Proposed model explicitly separates concurrency and parallelism and indicates further steps to automatic reprocessing programs for making them better tuned to modern architectures.

Index Terms—computer languages, control structures, concurrent structures, Logic, Graph theory.

—————————— ! ——————————

1 INTRODUCTION

Every algorithmic language describes decision actions

using logic statement of selection:

• “if” to choose one of two options • “case of” to choose options from more than two • “while” when our decision depends on condi-

tions with uncertain time trigger or other inde-pendent parameter change

This is well supported by classification of relations intro-duced by E. Kant [1], whom I consider as a first theoreti-cal programmer, opposing to a sentimental story of Ada, lady-lover of lord and part-time poet Byron. (Frankly, Nabokov’s ADA makes much more sense to me). E.Kant classified statements in terms of relationships and possible interactions between elements involved. Accord-ingly E. Kant an object might correspond, relate, interact with others using the following relationships:

• one-to-one • one-to-many • many-to-one • many-to-many

And it seems to me nice and easy, provided we make de-cisions where to go, what to choose and our decisions are mutually exclusive. That is why, by the way, each proces-sor instruction set has operator XOR and set-and-wait. 2. NEW CONTROL SCHEME Unfortunately, or fortunately our decisions are not al-ways that simple as presented above: we can be friendly with different groups of people, make not mutually ex-clusive decisions, starts selective actions with various taboo: “you can go your party but you do not drink and back before 11pm!” - remember? ;), Etc, etc.

And this is all executes at the same time… Thus E.Kant diagram should be extended, one option of extension, called GLM is shown below on Figure 1. GLM stands for graph logic model to describe mutual dependency of various kind, was successfully applied in real world applications, including active conditional con-trol systems, active safety monitoring systems, overpow-ers descriptive power of Markov and Bellman models and similar. Accordingly GLM, leaving one state, say “a” we might describe our leaving conditions using logic basic operators {AND, OR, XOR} attached to a leaving end of the links between “a” and neighbors.

Figure 1. Graph logic model of interactions between nodes

Note that, at the same time that various options are pos-sible - selection of leaving conditions to several neighbors using {OR} on each out-coming link, or broadcasting to all neighbors through all out-coming links using {AND}, or picking just one and only neighbors using {XOR}. Still, we think that we are the important ones and make impeccable decisions. This stands while we act and others just follow... But how about civil disobedience (for more on the subject I recommend to read Henry David Thoreau ‘On civil dis-obedience’) or Gandhi active resistance, when no matter what and which government (US and UK in these exam-ples respectively) is instructing us we are not following and note here - act differently?

Figure 1. Graph logic model of interactions between nodes (agents)

Note that at the same time selection of leaving conditions to several neighbors using {OR} on each out-coming link, or broadcasting to all neighbors through all out-coming links using {AND}, or picking just one and only neighbors using {XOR} becomes possible.

But still, we think that we are the important ones and make impeccable decisions. This stands while we act and others just follow...

But how about civil disobedience ( for more on the subject I recommend to read Henry David Thoreau ‘On civil disobedience’ ) or Ghandi active resistance, when no matter what and which government (US and UK in these examples respectively) is instructing us we are not following and note - act differently.

How to describe Vishi’s collaborationism and deGaulle resistance at the same time existing in France during WW2? How to describe Italian type strikes when people sit in office and do nothing?

Did anybody spot - we are talking distributed computing now, as we have introduced various modes of reaction of opposite side and have to accept it’s own will to act on or without our “instructions”.

From now on interactions between nodes with logic based decision rules applied to “own socket” for both sides are assumed.!

All these examples of other nodes involvement in interaction enforce to attribute the same link twice - at the leaving end and at the incoming end with different logic operators if necessary, Figure 2.

Igor Schagaev

August 2012

ITACS Limited © 2013

———————————————— • Igor is with ITACS Ltd, 157 Shephall View, SG1 1RR,

Stevenage, UK. e-mail:[email protected]

f(x){LO_} {LO+}

LO = {XOR, OR, AND}

a b

GLM in brief

GLM stands for Graph Logic Model and is used to describe mutual dependency of various kinds. It has been successfully applied in real world projects, including active conditional control systems, active safety monitoring systems. Its descriptive power is greater than overpowers of Markov and Bellman models and similar techniques.

Figure 5 A graph logic model of interactions between nodes

Accordingly GLM, on leaving one state, say “a” on Figure 5, we might describe our leaving conditions using basic logic operators {AND, OR, XOR} attached to a leaving end of the links between “a” and neighbours. We introduce (Figure 6) a link as a core of a model with leaving and arriving conditions combined into an arbitrary function f(x). This defines dependencies between a and b nodes.

Figure 6 Semantics and logic of link

Various options are possible to characterise the leaving conditions toward various neighbours. The modality of leaving might be expressed using OR on each out-going link. In turn, a broadcasting mode to all neighbours through all-out-going links is described using AND operator on each leaving end of edge; finally, picking just one or select concrete neighbours is possible using operator XOR.

�13

NOT IEEE TRANSACTIONS OR JOURNAL, THIS IS ITACS OFFICIAL PUBLICATION 1

Control operators vs Graph Logic Model

Igor Schagaev

Abstract—Simple paradigm to unite control operators for programming languages into one scheme using graph-logic representation of relations between agents (or elements of interaction) assuming independence of behavior for each element is presented. Shown that power of this structure exceed known models of description of behavior for concurrence and parallelism. Proposed model explicitly separates concurrency and parallelism and indicates further steps to automatic reprocessing programs for making them better tuned to modern architectures.

Index Terms—computer languages, control structures, concurrent structures, Logic, Graph theory.

—————————— ! ——————————

1 INTRODUCTION

Every algorithmic language describes decision actions

using logic statement of selection:

• “if” to choose one of two options • “case of” to choose options from more than two • “while” when our decision depends on condi-

tions with uncertain time trigger or other inde-pendent parameter change

This is well supported by classification of relations intro-duced by E. Kant [1], whom I consider as a first theoreti-cal programmer, opposing to a sentimental story of Ada, lady-lover of lord and part-time poet Byron. (Frankly, Nabokov’s ADA makes much more sense to me). E.Kant classified statements in terms of relationships and possible interactions between elements involved. Accord-ingly E. Kant an object might correspond, relate, interact with others using the following relationships:

• one-to-one • one-to-many • many-to-one • many-to-many

And it seems to me nice and easy, provided we make de-cisions where to go, what to choose and our decisions are mutually exclusive. That is why, by the way, each proces-sor instruction set has operator XOR and set-and-wait. 2. NEW CONTROL SCHEME Unfortunately, or fortunately our decisions are not al-ways that simple as presented above: we can be friendly with different groups of people, make not mutually ex-clusive decisions, starts selective actions with various taboo: “you can go your party but you do not drink and back before 11pm!” - remember? ;), Etc, etc.

And this is all executes at the same time… Thus E.Kant diagram should be extended, one option of extension, called GLM is shown below on Figure 1. GLM stands for graph logic model to describe mutual dependency of various kind, was successfully applied in real world applications, including active conditional con-trol systems, active safety monitoring systems, overpow-ers descriptive power of Markov and Bellman models and similar. Accordingly GLM, leaving one state, say “a” we might describe our leaving conditions using logic basic operators {AND, OR, XOR} attached to a leaving end of the links between “a” and neighbors.

Figure 1. Graph logic model of interactions between nodes

Note that, at the same time that various options are pos-sible - selection of leaving conditions to several neighbors using {OR} on each out-coming link, or broadcasting to all neighbors through all out-coming links using {AND}, or picking just one and only neighbors using {XOR}. Still, we think that we are the important ones and make impeccable decisions. This stands while we act and others just follow... But how about civil disobedience (for more on the subject I recommend to read Henry David Thoreau ‘On civil dis-obedience’) or Gandhi active resistance, when no matter what and which government (US and UK in these exam-ples respectively) is instructing us we are not following and note here - act differently?

Figure 1. Graph logic model of interactions between nodes (agents)

Note that at the same time selection of leaving conditions to several neighbors using {OR} on each out-coming link, or broadcasting to all neighbors through all out-coming links using {AND}, or picking just one and only neighbors using {XOR} becomes possible.

But still, we think that we are the important ones and make impeccable decisions. This stands while we act and others just follow...

But how about civil disobedience ( for more on the subject I recommend to read Henry David Thoreau ‘On civil disobedience’ ) or Ghandi active resistance, when no matter what and which government (US and UK in these examples respectively) is instructing us we are not following and note - act differently.

How to describe Vishi’s collaborationism and deGaulle resistance at the same time existing in France during WW2? How to describe Italian type strikes when people sit in office and do nothing?

Did anybody spot - we are talking distributed computing now, as we have introduced various modes of reaction of opposite side and have to accept it’s own will to act on or without our “instructions”.

From now on interactions between nodes with logic based decision rules applied to “own socket” for both sides are assumed.!

All these examples of other nodes involvement in interaction enforce to attribute the same link twice - at the leaving end and at the incoming end with different logic operators if necessary, Figure 2.

Igor Schagaev

August 2012

ITACS Limited © 2013

———————————————— • Igor is with ITACS Ltd, 157 Shephall View, SG1 1RR,

Stevenage, UK. e-mail:[email protected]

f(x){LO_} {LO+}

LO = {XOR, OR, AND}

a b

§  Linkdominatesnode§  Leaving≠Incomingcondi7ons§  EachlinkabributedbyLO-andLO+

EvolvingSystemsatmedium–RTModels–DependencyMatrixDM3

Real-<me–controlloop

FX Y

feedback

Flightdataself-

dependencies

Flightdatamarginsperflight

mode

Flightdataaffiliationtoaircraftelements

Flightmodeself-dependencies

Dependenciesofaircraftelementsuponflightmode

ElementDependencies

Matrix

2

1

FlightdataFlightmodeAircraftelements

FlightdataFlightmodeAircraftelements

DependencyMatrix(DM):(usingaircra>asanexample)

§  XnowisX(x1,x2,…xN)and{x}arenotlongerindependent

§  Fischanging(evolvingasproper7esofanobjectmodify)

§  PhysicaldependenciesofanobjectarealsoevolvingandthisprocessmustbedetectedandaddressedinRT

EvolvingSystemsDM3:aircraHreal-<meac<vesystemcontrol

It is called conditional monitoring, condition-based maintenance or similar. It is very likely that the designers of the Shuttle did it all and keep doing it again…

A much more realistic picture what is going on is illustrated by bottom left corner square - conditions of our system deteriorate as shown and even when timely maintenance has taken (not always true in the world ruled by profit and greed) the quality of maintenance is falling due to human factor, incompetence and objectively - due to growing complexity of our systems and products.

Thus we have to make current real knowledge, available and received in real time information aggregated and apply every moment of system operation. If we can do this - right bottom corner box illustrates one real system operation implementing active system control for aircraft we will be able to make aerospace safer. The greatest difference between right bottom corner box and the rest is it is based on real data and reduce probabilistic “guestimation” to the limit we can even ignore. Figure 25 explains how to aggregate data and model about an object.

Figure 25. Active system control: a model and flight data

How it works together was explained before in math section, Figure 18. The good point is active system control with imbedded evolvement is much closer to reality than existing schemes or theories and as we already wrote: The power of any theory is in predictions and our abilities to apply them.

�41

This is what we model…

This is what we record…

itworkstogetherandac7vesystemcontrolwithimbeddedevolvementismuchclosertorealitythanexis7ngschemesortheoriesandaswealreadywrote:

Thepowerofanytheoryisinpredic9onsandourabili9estoapplythem….

EvolvingSystemsDM3:measuringaprogress

Real'mepredic'onsandcontrolbeforeanythinghappen;gaininefficiency20%,safetyanorderofmagnitude.

(More about aviation safety see : https://www.academia.edu/8637255/Active_System_Control)

As I wrote in ONBASS (FP6, EC) project in 2004, deliverable D1_3:

“The information gained from rapid fault detection can be used to at least warn the crew of impending danger and in some circumstances suggest evasive action to conserve, or improve their own and their aircraft’s safety. The key point here is the importance of minimising the latency time

between a fault being detected and the active reaction to it by the safety management system.”

How we can do this? Well, there is another picture (Figure 24) below that highlights required steps, more details can be found in [SK14].

Figure 24. Evolving process of active system control for aircraft

We all aware about reliability estimation based on natural assumption of system deterioration, simulated by exponential distribution - left top corner of Figure 24. It is pure guessing game as nature is not aware about Poisson, Bayes or other people existence or assumptions.

Even then we are trying to apply various tricks using distributions to estimate condition of a system and guess when it is required to do maintenance - right top corner of the Figure 24.

�40

EvolvingConceptinComputerArchitectureandSystemSoHware

Figures 10 and 11 are self-explanatory; mored details might be found in [CS15].

As already presented [SBM14] we must address evolving properties and ability of reconfigurability for performance, reliability and energy-smart functioning at all levels of the system design, including system software - right side of Figure 12.

Figure 12. Performance, reliability and energy evolvement for computer design

Clearly, supporting the property of evolvability requires modifications to almost all elements of architecture. As we have to exclude complex instructions from the processor architecture, redesign the memory to enable access to byte, word, double words with minimum energy; for the system software in thelanguage area we have to reduce the complexity of data structures and , introduce new control structures that fit the purpose and exclude the now obsolete ones.

�25

EvSy: System Properties evolution

8© Blaeser L., Monkman S., Schagaev I. Evolving Systems, Foundations of Computer Science, WorldComp2014

!

LANGUAGES

RUN-TIME

SYSTEM

SERVICE OPERATING

SYSTEM

R P

E

SYSTEM SOFTWARE HARDWARE

EvolvingConceptinSystemSoHware:Language

Upgradingdataandcontrolstructures

Seemoreinourbook:hbp://www.springer.com/gb/book/9783319294636

EvolvingConceptinSystemSoHware:Programming,LanguageRestructuringprogramschemagraphs(C,D,P)


!

i-th layer

CONTROL PREDICATE DATA

EvolvingConceptinSystemSoHwareUserAlgorithms-Revamp

finding parallel branches of programs and independent data elements. However, expecting pure parallelism is hardly feasible: what is initiated as parallel segments ends up ultimately in concurrent mode, competing for a resource such as a socket, printer, data concentrator, etc. The rare exception, such as graphic processors with high numbers of SIMD-like processors just proves the rule. The simple notation similar to one introduced in http://www.it-acs.co.uk/files/Transaction_GLM.pdf can describe program structures and hardware structures consistently in terms of co-existing concurrency and parallelism. GLM explicitly separates parallel and concurrent elements in the system description by introducing logic operators in the program graph for incoming and outgoing ends of edges. The application of the logic operator XOR (exclusive OR) on an input or output of an edge defines ALL possible concurrencies in the program graphs. In turn, all possible parallelism in the control graph are defined by finding all outgoing or incoming edges explicitly described by the AND operator. The same approach might be applied for the data and predicate dependency graphs of the CDP model. Having a correct program, CDP and GLM can then be applied to extract the parallel segments and data paths and help in reducing concurrency. This reversed programming gives us a chance to play with the software and monitor software redundancy, (deliberately introduced at the recompilation phase) and hardware redundancy (introduced at the design phase) on the fly. It also enables to use reconfigurability of the system for performance, reliability, or energy-smart functioning when it is necessary.

Figure 5 proposes sequence that clearly separates properties required at the program writing phase with properties required during execution as latter are dependent on the available hardware resources available and changeable during execution. This way hardware features (that might be dynamically adapted during runtime) become represented in the program logic.

Fig. 5 Making parallel

4. System software for evolving systems

A new language is needed to naturally express algorithms in a form that supports program recompilation into a redundant form that fits the “hardware view”. This does not mean that other programming paradigms such as structured or OO are no longer useful. It means though that they have their limits and serve mostly for user convenience and interfacing. The proposed paradigm serves to improve performance of the end product by design of a new reconfigurable architecture, system software and transformation of existing software into a form that is efficiently

executable by adaptable hardware. Note that parallelisation might be applied to all three graphs: control, data and predicate, deducing the best parallel form. The availability of hardware serves as the termination condition for this algorithm. The same algorithm might be reapplied during execution.

The system software for next generation of evolving systems includes a new modular programming language called Active Language (AL) and two operating systems: a runtime system, called the Active Reconfigurable Run Time System (ARRUS) and service operating system (SOS). AL and ARRUS are tightly coupled, as AL needs runtime support for some features, such as recovery go program.

The language AL derivates from Oberon [26], [27] and COMPOSITA [36,37], includes the following new features:

- A new data structure is introduced that eases the mapping of data to memory (dual string model);

- GLM extensions is exploited in the control and operator model representation;

- Separation of interface and implementation to support dynamic software and hardware reconfiguration

- Reduction number of supported data structures - Physical separation of constant, global and local variables

and introduction of recovery points [18] - Support for recovery and reconfiguration points at the

module level using special program structures

AL revises language constructs such as unbounded loops and introduces calculation of upper execution times and stack sizes to ease certification. Rigorous memory management implemented without pointers and references. AL inherited from COMPOSITA that programs are entirely composed of active components which govern strict encapsulation, dynamic wiring with a dual concept of offered and required interfaces and communication-based interactions (Fig.6).

Fig. 6 Hierarchical component structures

As the language is based on hierarchical composition and does not employ any ordinary pointers or references, surrounding components properly controls the deletion of components and no garbage collection is needed for safe memory management [36,37].

Figure 7 shows an example of a component structure, where a component can contain an inner network of sub-components.

Communications follow a formal protocol written in an EBNF-like notation. Due to the strict encapsulation the components and can be easily mapped to various hardware architectures. It inherently enables parallelism (N components may be scheduled on up to N processors)

operator. The same approach might be applied for the data and predicate dependency graphs of the CDP model.

Moving forward, obvious questions arise: “can we prove that the hardware representation for the chosen algorithm is parallelized in its maximum possible way? How does this solution correspond with limitation of hardware resources?” Another question of principle importance is:

“Is there a way of knowing the correctness of program

structures to generate, starting from sequential programs, hardware efficient programs in its maximum parallel and minimum concurrent form?’

The answer to this question is a part of the challenge of ERA. Having a correct program, CDP and GLM can then be applied to extract the parallel parts and help in reducing concurrency. This reversed programming gives us a chance to play with the software and monitor software redundancy, (deliberately introduced at the recompilation phase) and hardware redundancy (introduced at the design phase) on the fly. It also enables monitoring of both: performance and reliability, if necessary.

Fig. 4 presents the generalized scheme of parallelisation for a correct sequential algorithm, using CDP and GLM.

This scheme clearly separates properties required at the program writing phase with properties required during execution as latter are dependent on the available hardware and its organisation. Thus hardware features (that might be dynamically adapted during runtime) become represented in the program logic. A new language is needed of course to naturally express algorithms in a form that supports program recompilation into a redundant form that fits the hardware view. This does not mean that other programming paradigms such as structured or OO are no longer useful. It means though that they have their limits and serve mostly for user convenience and interfacing.

The new proposed paradigm serves to improve performance of the end product by design of a new reconfigurable architecture, system software and dynamic transformation of existing software into a form that is efficiently executable by adaptive hardware: Evolving Reconfigurable Architecture. Interestingly, the algorithm of parallelisation might be applied for all three dependency graphs: control, data and predicate and therefore deduce the maximal parallel form. The availability of hardware serves as the termination condition for this algorithm.

Fig.4. ERA parallelization algorithm of sequential algorithms

IV. ERA SYSTEM SOFTWARE The system software for ERA includes both, the design of

a new modular programming language called Active Language (AL) and a runtime system, called the Active Reconfigurable Run Time System (ARRUS). AL and ARRUS are tightly coupled, as AL needs runtime system support for some of its features, such as recovery. The language has to be able to describe active processes and is in fact a direct derivative of Oberon [21], [22] that includes the following new features:

- A new data structure is introduced that eases the mapping of

data to memory (dual string model). - GLM extensions will be exploited in the control and

operator model - Separation of interface and implementation to support

dynamic software and hardware reconfiguration - Deliberate reduction of the number of supported data

structures and other language features - Physical separation of constant, global and local variables

and introduction of recovery points [18] - Support for recovery and reconfiguration points at the

module level using special program structures - A special language feature that allows safe HW access will

be introduced which results in a completely type safe language without loopholes.

- AL carefully revises dangerous language constructs such as unbounded loops and introduces calculation of upper execution times and stack sizes to ease certification

- Rigorous memory management strives to an implementation without pointers and references In the ongoing work, a prototype compiler and run-time

system for ERA were already developed. Direct support for reconfigurability and recoverability of

program structures at the language level eases the toleration of hardware faults and enables the handling of possible reliability and functional degradation during run time. The recovery point scheme will be embedded in the language and oriented on the programs and data structure. This reduces the overhead for recovery after malfunctions and eases the impact of possible permanent faults.

ARRUS has to support real-time processing as well as real-time reconfiguration of the underlying hardware elements and the respective network topology, including:

- Flexible dynamic hardware resource management - Performing of software reconfiguration to adapt to changes

of hardware states and system conditions - Management of hardware/software interactions in presence

of hardware faults - Hardware state monitoring and support of graceful

degradation using testing and recovery procedures and reconfiguration management To match the required features such as reconfigurability,

parallelization, real time, resilience to hardware degradation and distributed control processing, the ARRUS itself is built in a strict hierarchical manner, as it is illustrated in Fig. 5.

1. Debug sequential algorithm (SA) 2. Create a model of the SA as triple <C,D,P> where C,D,P are graphs of control, data and predicate dependencies of SA 3. Apply the graph logic model to modify C,D 4. Where possible substitute “strong” logic operators by “weak” ones. An “IF” might be substituted by XOR (to start) and OR, or AND or NOP, leaving an option to parallelise segments of the algorithm 5. Check all introduced XOR in sequence for potential concurrency in the algorithm – for the OS

218

An essential set of the above mentioned concepts have already been implemented in our component-based parallel programming language COMPOSITA [36],[37]. AL is a further development of this language, synthesising additional concepts for real-time and fault-tolerance. In COMPOSITA, programs are entirely composed of active components which govern strict encapsulation, dynamic wiring with a dual concept of offered and required interfaces and communication-based interactions (Fig.6).

!

!!! Figure 6 Describing hierarchical component structures !As the language is based on hierarchical composition and does not employ any ordinary pointers or references, surrounding components properly controls the deletion of components and no garbage collection is needed for safe memory management [36,37]. Figure 7 shows an example of a component structure, where a component can contain an inner network of sub-components. Communications follow a formal protocol written in an EBNF-like notation. Due to the strict encapsulation the components and can be easily mapped to various hardware architectures. It inherently enables parallelism (N components may be scheduled on up to N processors) as well as redundancy (the same components may be executed as multiple replicated instances). In the ongoing work, a prototype compiler and run-time system for evolving system were already developed. Direct support for reconfigurability and recoverability of program structures at the language level makes reconfiguration of system possible in case of hardware degradation due to faults or task special requirements of system power-saving operation or on the opposite boosting task by using maximum hardware resources for completion a task with required time limits. !For hardware fault tolerance especially due to substantial ration of malfunctions over permanent fault system software at the language level should be including recovery points for program at various levels of program presentation: procedure, module, task. Detailed description of language support of hardware fault tolerance using recovery points is present in [22], note here only that the recovery point scheme will be embedded in the language and

�15

client server

System

communication

!!!

BoundedBuffer

Producer

Producer

INTERFACE DataAcceptor; [ IN Element (x: INTEGER)] IN Finish END DataAcceptor;


Makingouralgorithmsevolvable

EvolvingConceptinSystemSoHwarePhasesRe-Design

algorithm will be visible and separated from hardware implementation. From another point of view we should improve efficiency of hardware and software work. So the question remains: How and what to modify in algorithms and implementations to achieve PRE-smartness of a system?

At first, the compilation process of a program should be “fine tuned” for execution on the specific hardware. Additionally, reconfiguring hardware before program execution also reduces overheads.

Examples prove nothing, unfortunately. In much more general terms program tuning for hardware performance or reliability or energy-smart operation is becoming some kind of reversed programming, when hardware, not the user (programmer) takes the dominant role. Thus we might separate explicitly “what is good for user from what is good for system and hardware” and, when possible, spread these requirements along life cycle of software and system development, as Table 2 illustrates.

Thus separation of concerns and goal of PRE-smartness requires supportive models of implementation from the system software point of view (language and run time systems) aiming improve hardware efficiency.

Table 2 Phases of software development

Two models we propose before for this are called control-data-predicate (CDP) and graph-logic- (GLM) models [2] .

3. Supportive models

Within CDP model each operator in a program has defined in terms of modifications of three connected graphs: control (C), data (D) and predicates (P). Thus operator is described by elements (nodes) in each graph; the volume of the resulting predicates, state registers, processor and program status words (PSW) physically represented in the hardware by so-called processor status registers, contributes into the “width” of each layer of these graphs. To support and exploit parallelism, all three graphs should be simplified by separation of data and control,

making them as independent as possible. Simplification of graph of predicates is achieved by deliberate fragmentation i.e. we propose that predicates should be processed when they needed for decision making and not stored in the hardware before that.

Support of reliability and fault tolerance requires detection of possible change of program state caused by hardware deviation and development of recovery schemes of hardware and software [22]. Therefore, any complex operator and hardware instruction respectively jeopardise the possibility of generating ‘snapshots’ of the previous hardware states as well as the flexibility of program segmentation, allocation and reconfiguration. Regretfully, in the vast majority of architectures, as well as languages (their compilers) and run-time systems the functions of data access and data processing are mixed, tightly coupled, and hardware state modification due to program execution is not controlled explicitly, making condition change latent and execution of a program unjustifiably complex.

In processors such ARM, Intel and SPARC, the arithmetic and logic unit (ALU), or even several of them, as well as shifters, registers, internal cache, special registers and pipeline sequencers are active during the execution of each instruction. The complexity of hardware handling becomes enormous: 75% of the die size is occupied by translation look ahead buffers, caches, synchronisation logic and pipelining. However, none of these overheads required from the programming language and program operators points of view.

Any condition of hardware related to the operator or instruction representation requires checking. This makes parallelism or reliability unachievable. Reasoning is different through: while for parallelism hardware should be designed as “flat as possible”, the reliability demands limitation of fault propagation through hardware schemes. The complexity of a system and the implementation cost of parallelisation or fault tolerance are directly related to the amount of the resulting modifications of the hardware and program states thus when P (predicate) is used only for the selection of the program flow, a special operator and instruction can be defined to generate the current value of P and store the result in a register, making system reconfigurability easier to achieve. To summarise, the implementation of parallelisation at the level of the instruction set, the design objectives will be:

- Simplification of predicate logic in a program; - Mapping of language operators as close as possible to the modified instruction set of the processor; - Reducing size of the program state required to be saved before instruction’s execution.

As a further improvement of parallelisation and at the same time concurrency reduction we need to handle the actions that were initiated in parallel, but eventually ended up in conflict of access to one or several resources, i.e. concur after resources. To describe this we introduce the graph-logic-model (GLM). Note that GLM might be applied for any of graph of the CDP model. Until now research in parallelism was mostly targeted at

User oriented phases (UW)

Concept Design Compilation Implementation

System software and hardware oriented phases

Analysis of the program through graph logic model to find intrinsic parallelism in control, data and predicate dependencies.

Recompilation of the program into parallel form with introduction of hardware configuration and reconfiguration features into program as well as concurrency management – formation of the execution string

Dual String Execution (New RT data structure that unites arrays and records)

EvolvingConceptinLanguage:Run-TimeSystemRevamp


!!

RESOURCE MANAGEMENT

FT SCHEDULER

HARDWARE MONITOR

MODULE LOADER

SYSTEM CHECK

Fault Log

Testing Procedures

Diagnostics

MAIN MONITOR

FT INTERRUPT HANDLER

APPLICATIONS

RECONFIGURATION MONITOR

User Space Runtime

EvolvingArchitecture:Zones,Interac<ons,Syndromes

Reconfigurability of hardware

17

How to put all this together?

199$

By$following$these$principles$the$processes$of$design$and$development$of$a$new$architecture$can$be$defined.$$

$Figure+631.+System+zones+from+a+information+processing+point+of+

view+

Figure$6?1$ shows$ a$ computer$ system$as$ three$ semantically$ different$ (from$ the$point$ of$ view$ of$ information$ processing/transformation)$ elements.$ The$principles$mentioned$above$might$be$applied$at$the$level$of$each$element,$which$will$help$into$designing$a$more$efficient$computer$system.$$

$Figure+632.+Information+processing+in+ERA+

199$



view+



213$

• External$elements$responsible$for$exercising$GAFT$and$making$decision$on$

configuration$/$reconfiguration$if$necessary$

• Internal$elements$capable$of$initiating$the$required$sequence.$$$

Indeed,$ in$ a$ regular$ computing$ system$when$ there$are$ faults$ in$ the$processing$

logic,$to$expect$that$the$processor$is$able$to$perform$self?healing$and$then$control$

and$monitor$configuration$of$the$rest$of$the$system$is$unrealistic.$We$propose$a$

possible$solution$as$described$below.$

$

Figure+637.+Processor+structure+with+“separation+of+concerns”+

Figure$6?7$shows$conceptually$the$ERRIC’s$active$zone$divided$by$two$AU$and$LU$

elements.$

To$ be$ able$ to$ trust$ information$ regarding$ the$ status$ of$ an$ element,$ every$

checking$signal$about$the$condition$of$registers$(not$shown),$memory$units,$AU$

and$ LU$ as$ well$ as$ control$ unit$ should$ be$ aggregated$ in$ syndrome.$ The$

implementation$scheme$of$fault$tolerance$separates$the$passive$zone$and$active$

zone$ of$ the$ proposed$ architecture.$ A$ clear$ separation$ of$ the$ functions$ of$

© Blaeser L., Monkman S., Schagaev I. Evolving Systems, Foundations of Computer Science, WorldComp2014

Reconfigurability of hardware

17

How to put all this together?

199$



view+



199$



view+



213$

• External$elements$responsible$for$exercising$GAFT$and$making$decision$on$

configuration$/$reconfiguration$if$necessary$

• Internal$elements$capable$of$initiating$the$required$sequence.$$$

Indeed,$ in$ a$ regular$ computing$ system$when$ there$are$ faults$ in$ the$processing$

logic,$to$expect$that$the$processor$is$able$to$perform$self?healing$and$then$control$

and$monitor$configuration$of$the$rest$of$the$system$is$unrealistic.$We$propose$a$

possible$solution$as$described$below.$

$

Figure+637.+Processor+structure+with+“separation+of+concerns”+

Figure$6?7$shows$conceptually$the$ERRIC’s$active$zone$divided$by$two$AU$and$LU$

elements.$

To$ be$ able$ to$ trust$ information$ regarding$ the$ status$ of$ an$ element,$ every$

checking$signal$about$the$condition$of$registers$(not$shown),$memory$units,$AU$

and$ LU$ as$ well$ as$ control$ unit$ should$ be$ aggregated$ in$ syndrome.$ The$

implementation$scheme$of$fault$tolerance$separates$the$passive$zone$and$active$

zone$ of$ the$ proposed$ architecture.$ A$ clear$ separation$ of$ the$ functions$ of$

© Blaeser L., Monkman S., Schagaev I. Evolving Systems, Foundations of Computer Science, WorldComp2014

Reconfigurability of hardware support: T-logic scheme

18

for single computer for multiprocessor system

Active Zone

ERRIC

Passive Zone

RAM RAM RAM

Memory used by ERRIC

Idle memory

T-logic ERA interconnector

ARCH

ITEC

TURE

BUS

- HW element should !“switch itself”, “be switched on” - !for PRE purposes under control of Run-time system

FP7-ICT-2013-4 PRESSA

© PRESSA consortium 2012 28

Figure 9 Indicative PRESSA configuration on wafer

FP7- ICT-2013-10 PRESSA

Proposal Part B: Page 22 of 59

Figure 7 Indicative reconfigurable architecture of PRESSA

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

ERRIC

MEMORY

IOE

IOE

IOE

IOE

IOE

IOE

IOE IOE IOE IOE IOE IOE

IOE IOE IOE IOE IOE IOE

IOE

IOE

IOE

IOE

IOE

IOE

© Blaeser L., Monkman S., Schagaev I. Evolving Systems, Foundations of Computer Science, WorldComp2014Seemore:hbp://www.springer.com/gb/book/9783319150680

EvolvingConceptinComputerArchitecture:

Seemore:hbp://www.springer.com/gb/book/9783319150680

EvolvingSystems:InsteadofConclusion

Workdonesofar:books,patents,papers,prototypes

Nextstep?:Academia.edusessions:

hbps://ec.europa.eu/futurium/en/content/theory-evolving-systems

hbp://www.springer.com/gb/book/9783319150680

hbp://www.springer.com/gb/book/9783319294636

hbps://www.academia.edu/s/4cd5ae8775

Nextstep?:FutureEmergingTechnologiesIni<a<ve:

hbps://www.academia.edu/26269108/Principle_of_Ac7ve_Condi7on_Control_Impact_Analysis

hbps://www.academia.edu/7120548/Method_and_apparatus_of_ac7ve_system_safety

Whatelse

?

Documents

Evolving Systems