This paper proposes a modified, genomial, version of function - architecture co-design rnethod so that wider cvaluation of architecturcs from both functional arrd structural point of view can bc pcrformed. The topological rnodellirrg technique is used to creatc thc Computatiorr Irrdependent Modcl that is abscnt in thc original method. A case study has been performcd that clarifics thc kcy idcas of this approach.
The rising complcxity and quality rcquircmcnts for modern embedded systems
calls for dcvelopmcnt and use of highly intcgrated and formal dcsign approaches.
Many rescarchers agrec that a novcl perception of cmbedded architecture is
required - one that does not draw strict boundaries between hardware and softwarc
components of a single system. The problem of unified view on embedded
systems is addressed by various formal techniques, such as function - architecture
co-design [
The architectural genome 'I'he most significant shortcomings of function - architecture co-designapproach can be corrected by inclusion of evolving architectures in its meta-model. In general, the processof architecting should based on both functional and structural aspects of the system. Although the functional specification still remains a cornerstone for developmcnt of any architecture, the implementation details must not be left out of thc architecting scope. The method should provide means of traceability; in the context of Model Drivcn Architccture (MDA), the trail is used to provc corrcctness of transformations. Finally, multiple iterations of thc dcvclopment process must be properly supported. The architecture, although being modified, should keep its original integrity without any ad hoc solutions. Such evolving architectures are materialised in the modified co-designmethod as the " architectural genome" - a collection of formal dcscriptions and transformations. It acts as a repository that holds architectural components, cxpresscd in pre-defined fbrmal notation, supports join, merge and other operations on them, and enables thc dcveloper to revisc and extcnd its contents during the developmcnt process. The dcscription of embcdded architecturcs has been accordingly extended and consists of: - sct of functional rcquirementsor functional spccification(X : {X0...X1}); - set of architectural constructs (A : {A0 . . . A}) as a combination of primitivcs: elements of thc utilized programming language (r), servicesprovided by operating system (O) and services provided by hardware components ( H ) ; - set of rcquirements enforced on the model of communications (Cr). It must be noted that the set of architectural constructs (set A) includes members of various degreesof complexity and levels of abstraction, as listed below (in order of increasing complcxity) : - Architectural primitives that are pcrceived as "black boxes". Their descriptions are included in the gcnome before devclopment process starts, are trcatcd as read-only information and can bc freely re-used. The primitive set P : {O, H, L) contains both abstract and real-world elemcnts. - Thc set of architectural constructs contains various combinations of primitives, therefbre significa,ntlyrnore cornplex parts of the system can be developed. They still are not self-sufficientbut neverthelesscan be included in the models of either current or future svstems. The specifications of members o f t h i s s e t K : { { O r , H r , L t } , { O r , H z , L z } . . . { O n , H " , L . } } a r e c r e a t e d by using merge operations on members of specific subsets of P. The set of architecturc constructs is also suitable for re-use in other projects. - The set of architectures consists of implcmentation candidates that are fully functional and self-sufficient. Its members are creat,ed from t;he elements of set of architecture constructs and primitives (A: {{Kr, Pr}, {Kz,Pz} ...{Kn,P,}}), and differ fiom them by being non-universaland valid only within boundaries of a particular project.
Genomial architcctures are created as abstract entities (if the original requirernents do not irnply inclusion of particular COTS components), a,nda,fterverification thc abstract parts are gradually replaccd with their real-world equivalcnts.
Although thc genomial approach scems to bear a strong resemblance to thc well-known componcnt-based architecture dcsign and style-bascd development methods, it, shows significant dilfcrcnces from l,hem. Genomial architecture constructs, unlike those of the component-based architecture, can be extcnded at will. If some of thcm are perccived as black boxes, it is an cxclusion, not a rulc. Also, architectural dcsigns derivcd from a common genomial basc, do not havc the same vocabulary. In most cases,their constructions arc only distantly related: thcy may be dcrivatives of common abstract objects.
Extension of function - architecture co-design approach also deals with
selection of suitable formalisms with emphasis on aspccts significant to architecture'
Onc of such methods is topological modclling of functioning [
:FIM gcnomial co-dcsign environmcnt is depicted in Figure 1. It covers all of thc problem and application domain specification needs as well as a part of funcl,ional description - the portion of it that deals with high-level abstractions. By using the topological model as basis, the white areas of functional specification can be fillcd in with descriptions in functional algebraic notation (e.g., CSP). This specia,lizedpart of functional specification can be created simultaneously with the macro-architecturc. Unlikc the sct of high-level functional properties, CSP-cxpresscd requirements do not havc to exist a priori. 3
description language requirements
Sincc thc gcnomial co-design process is intendcd to cover all levcls of MDA,
including transition betwcen CIM and Platform Independent Model (PIM)' all
f'eaturesof it must be applicable to functional specificationsand architectural
entities alike. To keep thc framework of genomc as universal as possible, operations
on architecture should be performed only on such essential properties that are
provided by the most "minimalist" architecture description languagcs (ADL).
As stated in [
I : { P r . . . P ^ } ; m } 0 B I m p l e m e n t s ( X i . X j ) , w h e r e B - behaviour cxpressed in formal way (e.g., using CSP) as implementation of onc or morc functional properties {X} taken from the topological model, .I - sct of interfaces, P - set of ports that accommodate connectors.
Ports represent precise points of interaction betwecn componcnt and the outer world via connectors; at least one port per interface is required. Likewise, architcctural configurations dcfinc topology and can bc described as collections of components and connectors arranged in such a way that no component remains isolated and each connector has exactly two ports (fl and Pi) connected. A : { C t . . . C , , , C n t. . . C n ^ } ; Vl e lCn1 . . . Cr^)(l Joi,ns(P;, Pi)), where Cn - set of connectors.
Architectural configurations represent either full or sub-architectules. A configuration dcpicts full architccturc if and only if it includes all functional properties X of a particular topological modcl; othcrwisc, it reprcscnts a sub-architecture. With these defirritions rna,de,general-purpose set operations on architectural configurations can be devised: - Inclusion of components is expressed as union of sets of their intcrfaces and merger of behaviour descriptions: C t U C z : B r U 8 2 , 1 1 U1 2 Likewise, union of architect,ural configural,ions is expressed as:
A t U A z : C r l ) C 2 , C n l u C n 2 - Split of a component is a relative complement operation on its interface set; a new behaviour is also derived: Ct\Cz - Bt\82,.I1\.I2 Split of architectural configuration:
Ar\Az: Cr\Cz,Cn1\Cn2 The actual implementation of thcsc operations is languagc-dependcnt, and is generally performed by automated means. 4
In order to dcmonstrate the nature of evolving architectures, the case study
involves development of a consumer-grade car navigation systcm. Thc uADL v2.0
architccture dcscription language [
The initial high-levcl design, as devised from thc non-formal natural-language description and rcprescnted by means of topological model of functioning, has been given in Fig. 2a. Acting as CIM if spcaking in terms of MDA, this model does not addrcss implementation-related problems and rcmains highly abstract, but neverttrelcss provides useful infbrmation that clarifics how the architecture should be built. The high-level modcl depicts main functional propertics that arc linked together by causal relationships, as wcll as ties with the surrounding environment, that, cxist beyond the developmcnt scope but, are sufficientlv close-coupledwith the system in question. The list of main functional propcrties (nodes) has been cxtracted from given description and forms the main cycle of functioning: a) manage power supply and initiate low-power mode; b) acquire GPS position data; c) prepare digital map data; d) display current map on scrcen; c) accept uscr's input commands from thumbwheel and react on them.
The system receivcs information and power from the environment, thus interacting with it: f) powcr from car battery (constant supply); g) power from ignition system (sporadically interruptcd supply); h) signal from GPS satellite system; i) graphical display image; j) user's input commands; k) digital maps liorn cxtct'rtal source (flash modulc).
In order to support proper GPS hot and cold start-up timcs, the model is refined further by expansion of node b (sec Fig. 2b) and now contains provisions for support of proprietary GPS low-power modcs. This extension allows for GPS module to be "woken up" for periodic cphemcris checks whilc the rcst of systcm rcmains in inactive state.
The topological model now contains a number of functional sub-nodes that form a first-level sub cycle: I) manage GPS power; m) manage act,iveexternal antenna; n) receive satellite signal; o) dccode position data.
Likewise, node c has becn extcnded for better understanding of map preparation phasc (seeFig. 2c). Maps in digital form are prc-loaded from external media, cached and sorted for fastcr accessto thcm, and selectcd for subsequent display on scrcen. Thc following functional nodes have been added in lincar manner: p) rcad maps from external media; q) cachc geospatial outlines of maps; r) dctermine map visibility; s) pre-load visible maps; t) place visible maps on coordinate grid.
Although refinement of the topological model of functioning can proceed further, the basic functionality has been already includcd. With that, transition to PIM can commcnce.
Each functional node prcsent in the topological model is being mapped onto an uniquc component in ADL namespacc,and cach arc is being reprcsented as ADL connector. In order to prescrve arc directions, a dcfault interfacc is created for each component with In or Out porl defined for each respective arc (see Fig. 3). Arcs that conncct the system with outcr world are omitted, and only thcir associated ports (or collections thercof) remain. Figure 5 dcpicts a naive architecture (designated A,) in box and arrow equivalent of rADL notation. -4,, is abstract, for no behaviour has been defined for any of its components, and still platform-independent. All components and constructions rcsident therein have been cntered into the repository of architectural genome after being sorted b y o r i g i n a n d c o m p l e x i t y :A : { A . } ; K : { a , b , c , d , e , l , m r n ) o , P , Q , r ,s , t } ; L : { } ; o : { } ; s : { } .
As the next stcp, contents of A,, arc being gradually replaced with their lcss abstract derivatives. This process is influenced by non-functional requirements that originate from both system's initial description and naturc of problcm dornain. Its source topological model contairn one first-order sub-cycle; there{bre, the sub-cycle has to be implcmented as a separatc thread that runs in context of thc main proccss (main cyclc of topological model). The following changesto architecturc A,, have becn made: - Sub-architccturcs of process (u) and thread cxecution models (o) have becn created and included in genome's repository; they both, although abstract, are opcrating system services:g : {u,u}; - Component b has bccn merged with sub-architccture u that together form bu. It now cxposesinterfaces of both b and u: b u: b u u ;K : { a , { b , b , } ,c ,d , e , l , m , n , o , P , Q , r , s , t } - Componcnts a, c, d, e are mcrged into new component z sincc they share a common exccution context (residc in thc same process): z : a U c U d " Ve ; K : { { b , b u } , { o , c , d , e , z } , l , m , n , o , p , q , r , s , t } - Componcnt z has been merged with z to form the main process zu: z u : z U u ; K : { { b ,b , } , { o , c ,d ,e ,z } , 1 , m , D ,o , P , q , r , s , t } ; - Since component b forms a separatc thread, its outer connectors can be implemented as shared variables and have been assigned typc C",. Their behaviour can now be specified,thus ttrey ceaseto be abstract:
L : { { C t , C z , C " , ) } ; - All other connectors reside inside a common exccution contcxt and will form programming language function entry and exit points (C"), depending on their direction:I : { {Cr, Cz,C",}, {C s, Cq,Cs, Cr,t,Cbz,C bs,C us,C"}} . The changed architecture is dcsignated A,,t and saved in rcpository: A : { { A , , , A _ r } } A I p L
Q-, t
- - T
I 1 " q ?',af6IKc)] r!L: v +car r
t-rli
By gradually supplying computation parts to components and extcnding them, thc architecture becomes complete and ready for implcmentation. Components whose bchaviour cannot bc implemcnted in software or it is impractical to do s<.rw,ill be excluded from their respective pa,rent configura,tions.One of such components is n that, in reality, performs functions of a GPS receivcr: - Component n is excluded from b; b is replaccd by derivative b, and b, with bu rr'.
b , ,: b \ n ; K : { { { b " , b , , , } , { b , b . } } , { a , c , d , e , z ) , l , r r l ,n , o ,P , Q ,r , s , t } - Connectors C1,2and C63 will be implemented as serial lines and typed as C":
O : { u , u , C r } Thc changed architecture is dcsignated A,,2 and savedin repository (seeFig. 4): A : { { A . , A , , , r A, - z ) } All of the changes made to architecture are reflected in the bopological model via PIM-CIM transformation. The model of architccture A.,,2ca,r1beconsidcred functionally complete and ready for transition to PSM. 5
The example of practical application of the genomial co-design approach shows some of thc possibilities offered by thc concept of cvolving arctritectures. With an established repository of ready-made architectures and their separate components, new systems can be created more effectively.Thus, a step is made towards reuse of models, specifications and code across single or multiple problem and application domains.
Further rcsearch has bccn planned concerning tool support and automated model checks.Its purpose is to improve merge and split operations on descriptions of behaviour so that their correctness and completeness can bc guaranteed bcfore and after each transformation of a model.
Thi,s work has been partly supported by the European Soci,al Fund wi'th'in the Nat,ional Programme " support for the carrg'ing out doctoral studg progran'L'sand post-d,octoralresearches"project "support for the deuelopment of doctoral studi'es at Ri,ga Techni,cal Uni,uersi'ty".