Gaining Composure by Losing Control		Date	2021-11-30
		Tags

What fol­lows is a pa­per that I sub­mit­ted for IN­COSE UK’s ASEC 2021 Con­fer­ence. Un­for­tu­nate­ly, the pa­per was not ac­cepted which is fair enough as the pre­sen­ta­tions that made it into the con­fer­ence were all in­cred­i­bly in­ter­est­ing, use­ful and well pre­sent­ed. How­ev­er, de­spite my pre­sen­ta­tion skills, this method brought a lot of ben­e­fit when used at Jaguar Land Rover and I present it here so that oth­ers can ben­e­fit from it too.

Many sys­tems processes leave most of their in­te­gra­tion ac­tiv­i­ties on the right-hand-­side of the Vee. This can re­sult in func­tion­al­ity be­ing lost in the gap be­tween sub­sys­tems or du­pli­cated across sub­sys­tems. These de­fects, em­bed­ded in the re­quire­ments, may only be­come clear dur­ing in­te­gra­tion test­ing or later where the cost of rec­ti­fi­ca­tion is high­er. This prob­lem is com­pounded by sub­-op­ti­mal com­mu­ni­ca­tion struc­tures that are in­her­ent in siloed or­gan­i­sa­tions and even more so when en­gi­neers are highly dis­trib­uted due to home work­ing.

In projects where new be­hav­iours (fea­tures) are con­tin­u­ously in­te­grated onto ex­ist­ing sys­tems, emer­gent be­hav­iours can oc­cur when new fea­tures in­ter­fere with ex­ist­ing ones. A mod­el-based whole sys­tem func­tional ar­chi­tec­ture would al­low us to un­der­stand these emer­gent be­hav­iours. Such a model would also pro­vide a “s­in­gle source of truth” that would aid in pre­vent­ing du­pli­cated re­quire­ments and high­light miss­ing func­tion­al­i­ty. Un­for­tu­nate­ly, ex­ist­ing meth­ods of func­tional analy­sis re­sult in sets of func­tions that can­not eas­ily be “stitched to­geth­er” to cre­ate such a mod­el.

Pre­sented is a novel ap­proach to func­tional analy­sis, in­spired by func­tional pro­gram­ming, that en­ables greater com­pos­abil­ity of the func­tions cre­at­ed. The method fo­cuses on the in­for­ma­tion flow around the sys­tem as the ba­sis of defin­ing func­tion­al­ity and pro­hibits the use of con­trol flow. This method has been in use within JLR for 3 years and is per­formed on all new fea­tures. This has re­sulted in a model with over 6000 func­tions from many con­trib­u­tors across the com­pa­ny. This model has al­lowed us to per­form analy­ses to catch emer­gent be­hav­iours of the fea­ture; more eas­ily per­form fail­ure analy­sis and gives us a stan­dard “cur­ren­cy” with which to cas­cade re­quire­ments to sub­sys­tems.

In­tro­duc­tion

Per­form­ing a func­tional analy­sis for a sys­tem is a com­mon step in the re­quire­ments analy­sis process. It al­lows sys­tems en­gi­neers to de­com­pose the ‘black box’ sys­tem re­quire­ments of a sys­tem of in­ter­est (SoI) into chunks that can be al­lo­cated to sub­sys­tems [p.48 SMC 2005]. Func­tional de­com­po­si­tion also en­ables meth­ods such as N² analy­sis so that en­gi­neers can de­fine bet­ter sub­sys­tem ar­chi­tec­tures to ful­fil their stake­hold­er’s needs.

Func­tions can there­fore form a “cur­ren­cy” which can be used for re­quire­ments al­lo­ca­tion and trace­abil­ity from a SoI to its sub­sys­tems; the method with which we use to cre­ate our func­tions is key to en­sur­ing that this later work is ef­fec­tive in cre­at­ing bet­ter sys­tem ar­chi­tec­tures.

The method pre­sented in this pa­per does not cover the iden­ti­fi­ca­tion of func­tions that are black­-box sys­tem lev­el; re­ferred to as fea­tures here­after. Rather, it cov­ers the de­com­po­si­tion of fea­tures to a level that can be al­lo­cated to sub­sys­tems. Fea­tures are of­ten de­vel­oped us­ing use case analy­sis; the fea­ture is the be­hav­iour of the SoI, in re­sponse to stim­uli dur­ing the use case, to achieve the goal and sat­isfy the stake­hold­er(s). Fea­tures can span mul­ti­ple use cas­es.

The method is only ap­plic­a­ble to the func­tional as­pects of a SoI; those where causal­ity flows from in­puts to out­put. It is not a good fit for mod­el­ling the physics of the use case where a para­met­ric model could be bet­ter used.

A Novel Method for Func­tional De­com­po­si­tion

Fea­tures of­ten have large over­laps with each oth­er; they re­spond to the same stim­uli, pro­duce the same ac­tu­a­tions or con­tain the same math­e­mat­i­cal re­la­tion­ships be­tween stim­u­la­tion and ac­tu­a­tion. If we were to treat these fea­tures as atomic units in the en­gi­neer­ing process, it would re­sult in du­pli­cated ef­fort.

This over­lap can also cause is­sues when the SoI is de­vel­oped it­er­a­tive­ly. This is the ap­proach to en­gi­neer­ing that the au­to­mo­tive sec­tor fol­lows. Each new sys­tem pro­duced is an it­er­a­tion of a con­tin­u­ously up­dated ar­chi­tec­ture. In these cas­es, there is an in­creased risk that new fea­tures will in­ter­fere with ex­ist­ing ones. This can cause un­de­sir­able emer­gent be­hav­iours. With­out analy­sis to spot these emer­gent be­hav­iours, they may only be caught dur­ing fi­nal val­i­da­tion of the prod­uct as the is­sues are in­her­ent in the re­quire­ments.

Many func­tional de­com­po­si­tion meth­ods treat func­tions as the process of com­plet­ing one of a se­quence of tasks that cul­mi­nate in the achieve­ment of the goal. Of­ten the se­quenc­ing of the func­tions is shown us­ing a con­trol flow graph. Ex­am­ples of this are Func­tional Flow Block Di­a­grams pre­sented in the NASA SE Hand­book[­NASA 2007] and SysML ac­tiv­ity di­a­grams [OMG 2018 SysML 1.6]. In­for­ma­tion flow is of­ten then added to the de­com­po­si­tion af­ter­wards (or not at all as de­scribed in the SE­BoK log­i­cal ar­chi­tec­ture pit­fall­s[SE­BOK 2020])

In this pa­per, a novel func­tional analy­sis method is pre­sented that ad­dresses these con­cerns whilst be­ing sim­ple enough for en­gi­neers to un­der­stand with min­i­mal train­ing. This method has been named the Miso method as the func­tions pro­duced can have mul­ti­ple in­puts but only one out­put.

The key idea be­hind the Miso method was the ques­tion:

Con­cerns for Func­tional Analy­sis Meth­ods

Be­fore de­vel­op­ing a new method for func­tional analy­sis, we iden­ti­fied stake­holder con­cerns that would need to be ad­dressed by the method. These con­cerns were dis­cov­ered through dis­cus­sion with many stake­hold­ers from around to busi­ness. To sum­marise, the new method should im­prove our ca­pa­bil­i­ties to per­form im­pact as­sess­ments and fail­ure analy­ses; pro­duce func­tions that are read­ily al­lo­ca­ble to the ex­ist­ing (and fu­ture) sub­sys­tems; and ease writ­ing, re­view­ing and val­i­da­tion of re­quire­ments. The method should also help us avoid an­ti-­pat­terns such as ‘hid­den’ in­for­ma­tion flow that can make fail­ure analy­sis and val­i­da­tion hard­er; let­ting the so­lu­tion in­form the de­com­po­si­tion which can cause no longer ap­plic­a­ble con­straints to af­fect the re­quire­ments; and help avoid de­com­po­si­tion to the wrong level of ab­strac­tion.

Miso Func­tions

A sign of a good method is re­peata­bil­i­ty: two en­gi­neers with the same in­puts, sep­a­rated so they can’t com­mu­ni­cate, should pro­duce the same out­come when fol­low­ing the method. With pre­vi­ous meth­ods of func­tional analy­sis, this did not oc­cur. En­gi­neers of­ten dis­agreed on the in­ter­faces of the func­tions. How­ev­er, they tended not to dis­agree on the in­for­ma­tion flows in a fea­ture. This ex­pe­ri­ence in­spired the key idea be­hind the method.

To en­sure re­peata­bil­i­ty, the en­gi­neer fol­lows a stan­dard method to iden­tify the func­tions. The en­gi­neer first iden­ti­fies all in­for­ma­tion that is flow­ing across the sys­tem bound­ary—s­tim­uli & ac­tu­a­tion­s—and the con­trol func­tions are just the de­pen­den­cies be­tween these in­for­ma­tion flows. If you were to have drawn se­quence di­a­grams to ex­press your use cases for the SoI, each mes­sage go­ing into or out from the SoI’s life­line is one of these bound­ary-cross­ing flows. This also en­sures a con­sis­tent level of ab­strac­tion across de­com­po­si­tions.

The main view of the Miso method is the en­hanced func­tional flow block di­a­gram[­Long 1995](e­qi­va­lent­ly, SysML Ac­tiv­i­ties). Think­ing of func­tions as the de­pen­den­cies be­tween in­for­ma­tion flows though gave the di­a­grams some in­ter­est­ing prop­er­ties: there is no con­trol flow in the Miso func­tional flow views which, some­what sur­pris­ing­ly, has not re­sulted in a loss of ex­pres­sive­ness. The dis­tinc­tive mul­ti­ple-in­put-s­in­gle-out­put sig­na­ture of the func­tions also arises from think­ing of func­tions in this way.

With the Miso method, writ­ing re­quire­ments be­comes an ex­er­cise in stat­ing which value is pro­duced by the func­tion for each com­bi­na­tion of in­put val­ues. This makes the re­quire­ments pro­duced much eas­ier to re­view as com­plete. This be­comes slightly more com­plex for state­ful func­tions as de­scribed later in this pa­per.

In JLR we cre­ated new stereo­types on our func­tion el­e­men­t—«sense» and «ac­tu­ate»—to rep­re­sent when in­for­ma­tion flow crosses the sys­tem bound­ary. This could also be achieved with ac­tiv­ity pa­ra­me­ters in an ac­tiv­ity di­a­gram as in Fig­ure 1. Though hav­ing spe­cific func­tion el­e­ments here gives us a stan­dard el­e­ment in the mod­el­ling tool to at­tach re­quire­ments for the SoI’s in­ter­faces.

Al­lo­cat­ing a Miso func­tion to a sub­sys­tem car­ries the mean­ing of al­lo­cat­ing the re­spon­si­bil­ity to cre­ate the in­for­ma­tion flow pro­duced by the Miso func­tion. That sub­sys­tem must also have ac­cess to the in­for­ma­tion that the func­tion re­quires at its in­puts. This leads us to­wards al­lo­ca­tion meth­ods where we can al­lo­cate our func­tions to min­imise in­for­ma­tion flow across in­ter­faces as a sort of N² as-y­ou-­go. Know­ing the de­pen­den­cies be­tween in­put and out­put val­ues can also give you an un­der­stand­ing of the ‘size’ of the com­pu­ta­tion a func­tion rep­re­sents (in rough big O no­ta­tion) and can in­form al­lo­ca­tion if com­put­ing power is a con­straint.

A Whole-Sys­tem Func­tional Ar­chi­tec­ture

:::

When it comes to reusing func­tions in a new fea­ture, if a func­tion has mul­ti­ple out­puts, there is a risk that the novel fea­ture will only use a sub­set of the out­puts in its be­hav­iour. This can lead to fea­tures pick­ing up un­re­lated re­quire­ments when traced to their func­tional de­com­po­si­tions. Miso func­tions solve this prob­lem el­e­gantly due to their sin­gle out­put—if you re­quire the in­for­ma­tion cre­ated by that func­tion then you reuse it, oth­er­wise, you do not.

An­other prob­lem that af­fects the com­po­si­tion of Miso func­tions into fea­tures is the in­ter­pre­ta­tion of con­nec­tors. SysML ac­tiv­i­ties and Simulink both treat the con­nec­tions be­tween func­tions as ‘pipes’. Un­like C func­tions where func­tions are called to re­turn a value and then dis­ap­pear back to obliv­ion, Miso func­tions should be in­ter­preted as ma­chines that are ‘al­ways on’ and there­fore, the in­for­ma­tion flows al­ways have a val­ue. For those in­ter­ested in cat­e­gory the­o­ry, be­cause of this, Miso func­tions could be mod­elled as a spe­cial kind of cat­e­gory known as a Freyd Cat­e­gory or Hugh­es’ Ar­rows [Hughes 2000].

The Miso method gives us the guar­an­tee that if an in­for­ma­tion flow is an in­put to a func­tion then the out­put de­pends on it. This, cou­pled with the li­brary and the whole-sys­tem func­tional ar­chi­tec­ture, al­lowed us to fol­low func­tional flow back and for­ward through our SoI. An­other way that the Miso method sup­ports this is by en­forc­ing that en­gi­neers spec­ify all pos­si­ble val­ues of each in­for­ma­tion flow and whether the func­tion gen­er­ates it as an event or a stream. By do­ing so, it is much eas­ier to ap­ply fail­ure key­words in a HA­ZOP-­like method and to work out which fail­ures are un­de­tectable and de­tectable. There­fore, this iden­ti­fied im­pos­si­ble re­quire­ments where the down­stream func­tions were re­act­ing to an un­de­tectable fail­ure.

In JLR, the whole sys­tem func­tional ar­chi­tec­ture took the form of a SysML model that aims to con­tain all con­nec­tions be­tween all us­ages of the func­tions in all pos­si­ble ve­hi­cles from 2019 on­wards. At the time of writ­ing, there are over 6000 func­tions in this ar­chi­tec­ture, each re­spon­si­ble for a unique in­for­ma­tion flow. This is ex­pected to grow at a lin­ear rate into the fu­ture as more fea­tures are added to ve­hi­cles bring­ing in new func­tions and doc­u­ment­ing legacy func­tions alike.

A di­a­gram view of this en­tire ar­chi­tec­ture would be be­yond com­pre­hen­sion, so tools have been de­vel­oped to cre­ate views scoped to in­di­vid­ual fea­tures on re­quest. Tools have also been de­vel­oped to en­able the fol­low­ing of up­stream & down­stream de­pen­den­cies be­tween func­tions so that fail­ure analy­sis can be traced from stim­uli to ac­tu­a­tion in the mod­el. This model pro­vides a firm foun­da­tion for the au­toma­tion of analy­sis of emer­gent be­hav­iours be­tween fea­tures given a be­hav­ioural spec­i­fi­ca­tion for each func­tion in a ma­chine-­parseable lan­guage.

In­for­ma­tion Flow & Val­ues

Defin­ing the ex­tent of pos­si­ble val­ues for each in­for­ma­tion flow is an im­por­tant part of the Miso method. Un­der­stand­ing the pos­si­ble in­put com­bi­na­tions and out­puts of a func­tion is a good way for us to en­sure that the re­quire­ments writ­ten from it are com­plete. There­fore, defin­ing the value range for each out­put of a func­tion is a manda­tory part of the method.

SysML Data Types pro­vide our main means of record­ing this in­for­ma­tion but a ta­ble view for each func­tion could suf­fice in a non-­mod­el­ing process. We took in­spi­ra­tion from func­tional pro­gram­ming’s use of al­ge­braic data types [Milewski 2015] to en­sure that the syn­tax for data types in the re­quire­ments was ex­pres­sive enough to cover ar­bi­trar­ily com­plex in­for­ma­tion.

We also de­fined the Noth­ing value as a spe­cial value that could be added to types to rep­re­sent a func­tion not pro­duc­ing any­thing. An ex­am­ple is when an event based «sense» func­tion is not sens­ing an even­t—in these cas­es, it is pro­duc­ing Noth­ing. This en­sures our re­quire­ments cover con­di­tions where there is no stim­u­lus and that they are eas­ily un­der­stood. This con­ven­tion was in­spired by the Maybe type used in many func­tional pro­gram­ming lan­guages [Lipo­vača 2011].

State­ful Func­tions

An im­por­tant part of the Miso method is the iden­ti­fi­ca­tion of whether an in­for­ma­tion flow is a to­ken (event based) or a stream (con­tin­u­ous) as it pro­vides us with an easy way of iden­ti­fy­ing whether a func­tion is pure or state­ful.

r0.5

Pure func­tions are those where, at any point in time, the out­put value is en­tirely de­fined by the in­puts. There­fore re­quire­ments au­thor­ing for a pure func­tion is triv­ial. If this con­di­tion is not true, then the func­tion must have mem­ory (s­tate). An im­pure func­tion is iden­ti­fied as one where there is at least one to­ken in­put but a stream out­put.

Many prob­lems can only be solved by im­pure be­hav­iours—any prob­lem that re­quires in­for­ma­tion to per­sist over time. To keep state away from pure func­tions, we ini­tially in­tro­duced a new stereo­type of func­tion—«­s­tore». A «s­tore» func­tion stores the last value of a to­ken and pro­duces it as a stream of the same type. A store func­tion can then be placed up­stream of the in­puts of a stream-pro­duc­ing con­trol func­tion to en­sure that it re­ceives only streams and is pure. With the ad­di­tion of «s­tore» func­tions, the meta­model of the lan­guage is com­plete with re­gards to be­ing able to fully ex­press be­hav­iour.

As more fea­tures were analysed us­ing this tech­nique, we no­ticed pat­terns oc­cur­ring with the in­ter­play be­tween «s­tore» func­tions and «con­trol» func­tions. One ex­am­ple of this is the state con­trol pat­tern. This pat­tern is shown in fig­ure 2. It was re­alised that this lit­tle sys­tem of «s­tore» and «con­trol» func­tions were act­ing equiv­a­lently to a state ma­chine. There­fore, a new stereo­type of func­tion—«s­tate­ful»—was cre­ated to en­com­pass this pat­tern. We then en­cour­aged en­gi­neers to draw state di­a­grams to rep­re­sent the be­hav­iour of these new func­tions to im­prove com­pre­hen­sion and com­mu­ni­ca­tion of re­quire­ments.

Sum­mary of the Miso Method

Fi­nal­ly, pre­sented is a sum­mary of the steps to the Miso method of func­tional analy­sis:

Iden­tify the In­ter­face of the Fea­ture—In the use cases for the fea­ture at hand, iden­tify where in­for­ma­tion flows across the bound­ary of the sys­tem. This could be in the form of stake­holder in­ter­ac­tions, sens­ing the val­ues of en­vi­ron­men­tal mea­sur­ables or ac­tu­at­ing ef­fects. For each of these iden­ti­fied in­for­ma­tion flows, iden­tify whether they are a to­ken or a stream and the range of val­ues that it has.

Analyse the De­pen­den­cies Be­tween In­for­ma­tion Flows—For each of the ac­tu­a­tions of our sys­tem in the use case we need to iden­tify which of the stim­uli we want it to de­pend up­on. If there is a de­pen­dency be­tween an ac­tu­a­tion and a stim­u­lus, the stim­u­lus in­for­ma­tion flow must be an in­put to the con­trol func­tion of that ac­tu­a­tion. Note that oc­ca­sion­al­ly, some con­trol func­tions will feed into more than one ac­tu­a­tion.

Iden­tify State—I­den­tify func­tions with to­kens go­ing in and streams com­ing out­—these are cases where store or state­ful func­tions are re­quired. We also iden­tify the need for tim­ing—­such as de­lays or de­bounces—as this too can be rep­re­sented with state­ful func­tions.

Refac­tor Your De­com­po­si­tion—No­tice when mul­ti­ple func­tions are con­sum­ing the same in­for­ma­tion flows and are do­ing some­thing un­der the same con­di­tions Where this hap­pens, we can cre­ate a new func­tion and in­for­ma­tion flow to rep­re­sent the con­di­tions be­ing met or not. Note that new con­trol func­tions should only be cre­ated if the in­for­ma­tion they pro­duce is used by two or more other con­trol func­tions. This refac­tor­ing can also be done in re­verse to merge ex­tra­ne­ous con­trol func­tions that are only pro­vid­ing their in­for­ma­tion to one other con­trol func­tion.

Con­clu­sion and Fur­ther Work

Re­fin­ing our ap­proach to func­tional ar­chi­tec­ture has given JLR a bet­ter un­der­stand­ing of its ve­hi­cle sys­tem by al­low­ing us to find in­ter-re­la­tions be­tween dif­fer­ent be­hav­iours that re­mained im­plicit in other meth­ods. This led to re­duc­tions in the time taken to per­form work such as func­tional fail­ure analy­sis, fea­ture re­quire­ments har­mon­i­sa­tion and re­view­ing of the pro­duced re­quire­ments. The fo­cus on the pos­si­ble val­ues of in­for­ma­tion flow and whether that flow was a to­ken or stream greatly aided in the au­thor­ing & re­view­ing of re­quire­ments pro­duced from func­tional analy­ses.

A re­lated ob­ser­va­tion was that if a func­tional de­com­po­si­tion had been per­formed by other meth­ods but did have all in­for­ma­tion flows iden­ti­fied, we could refac­tor it into Miso func­tions. Do­ing this refac­tor­ing work of­ten iden­ti­fied miss­ing in­for­ma­tion flows in the orig­i­nal func­tional de­com­po­si­tion of a fea­ture that were ei­ther left im­plicit by the en­gi­neer or for­got­ten. Al­though fol­low­ing the Miso method usu­ally re­sults in more func­tions than pre­vi­ous func­tional analy­sis meth­ods, each func­tion was both eas­ily jus­ti­fi­able and al­lo­ca­ble to the sub­sys­tems as­sur­ing us that the level of ab­strac­tion was good.

A ben­e­fit of hav­ing a whole sys­tem func­tional ar­chi­tec­ture model is that it al­lowed en­gi­neers to more eas­ily find the right in­for­ma­tion flows for their sys­tem. The model acted as a fo­cal point which al­lowed us to spot du­pli­ca­tions of be­hav­ior and, there­fore, ef­fort (often due to sim­i­lar fea­tures de­vel­oped by dif­fer­ent parts of the busi­ness). The fo­cal point the model pro­vided was use­ful when home work­ing be­gan as it pro­vided a com­mu­ni­ca­tion chan­nel for re­quire­ments be­tween sys­tems en­gi­neers in dif­fer­ent parts of the busi­ness that would not have ex­isted oth­er­wise.

The method pre­sented may also be use­ful for mod­el­ling busi­nesses processes where in­for­ma­tion flow of such a de­com­po­si­tion maps to the de­liv­er­ables in the process. Fol­low­ing the Miso method for de­scrib­ing busi­ness process may pro­vide a ‘good fit’ for a no­ta­tion to go with the points made by Dr Keith Col­lyer in his pa­per “Process Mod­els are not Flow Chart­s”[­Col­lyer 2020] Cur­rent­ly, busi­ness process mod­el­ling lan­guages such as ARIS and BPMN are con­trol flow based mak­ing the mod­els cre­ated in them flow charts. The phrase “In­for­ma­tion is more im­por­tant than the way you cre­ate it” from his pa­per chimes with the guid­ing phi­los­o­phy that we fol­lowed when de­vel­op­ing the Miso method.

Ref­er­ences

[SMC 2005] Space and Mis­siles Cen­ter US Air Force (2005) ’Sys­tems En­gi­neer­ing Primer and Hand­book’

[NASA 2007] NASA (2007) ‘NASA Sys­tems En­gi­neer­ing Hand­book’ Rev 1

[SE­BOK 2020] Alan Faisendier et al Log­i­cal Ar­chi­tec­ture Model De­vel­op­ment [on­line] Avail­able at: http­s://www.se­bok­wi­k­i.org/wik­i/­Log­i­cal_Ar­chi­tec­ture_­Mod­el_De­vel­op­ment [Ac­cessed 8 May 2021]

[Hughes 2000] John Hughes (2000) ‘Gen­er­al­is­ing Mon­ads to Ar­rows’ In: Sci­ence of Com­puter Pro­gram­ming 37

[Milewski 2015] Bar­tosz Milewski (2015) ’Sim­ple Al­ge­braic Data Types’ Avail­able at: http­s://bar­toszmilews­ki.­com/2015/01/13/sim­ple-al­ge­braic-­data-­types/ [Ac­cessed 8 May 2021]

[Lipo­vača 2011] Mi­ran Lipo­vača (2011) ’Learn You A Haskell For Great Good!’ Avail­able at: http­s://learny­oua­haskel­l.­com/­mak­ing-our-own-­type­s-and-­type­class­es/ [Ac­cessed 8 May 2021]

[Col­lyer 2020] Dr. Keith Col­lyer (2020) ’Process Mod­els are not Flow Charts’ In: ASEC 2020. IN­COSE UK.

Site proudly generated by Hakyll | Theme based on Oskar Wickström's Monospace Web.