Computers & Electronics

Embedded Component Technology for Complex Control Systems

Description
Embedded Component Technology for Complex Control Systems
Published
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  Embedded Component Technology forComplex Control Systems 2 Ricardo Sanz, 1 Carlos Mart´ınez, Manuel Rodr´ıguez andAdolfo Hernando Autonomous Systems Laboratory Universidad Polit´ecnica de Madrid Jos´e Gutierrez Abascal 2, 28006 Madrid, Spain  Abstract: The question of finding the best technology for software-based controller deployment is still open.One of the main problems is that computing infrastructures for controllers are composed byheterogeneous hardware and software platforms scattered over a set of heterogeneous networkiginfrastructures. The standardised object-oriented efforts done around the the OMG specifica-tions try to overcome some of the difficulties raised by this heterogeneity. Inside the DistributedObject Computing (DOC) landscape, CORBA is a well known framework for the constructionof modularised, object oriented, distributed applications. The CORBA object model, however, isnot enough when confronting the problems related to deplyment, configuration and evolutionarymaintenance of systems. This paper describes the ECF component technology specifically builtfor the construction of component-based, distributed embedded systems.Keywords: Components, Real-Time, Embedded, CORBA, CCM, Distributed ObjectComputing1. INTRODUCTIONControl systems are bassically built using software tech-nology. Specialized in the past, in recent years the domainof embedded software is turing into the use of tools and as-sets that come from the mainstream software engineeringdomain.This movement is motivated by the continuous increase incomplexity (Sanz et al., 1998) and the changes happenedin the embedded systems domain: but the question of finding the best technology for software-based controllerdeployment is still open. One of the main problems is thatcomputing infrastructures for controllers are composed byheterogeneous hardware and software platforms scatteredover a set of heterogeneous networkig infrastructures.The standardised object-oriented efforts done around thethe OMG specifications try to overcome some of the diffi-culties raised by this heterogeneity. Inside the DistributedObject Computing (DOC) landscape, CORBA is a wellknown framework for the construction of modularised, ob- ject oriented, distributed applications. The CORBA objectmodel, however, is not enough when confronting the prob-lems related to deplyment, configuration and evolutionarymaintencae of systems. This paper describes the ECFcomponent technology oriented towards the constructionof component-based embedded systems.In the last years, the embedded systems domain is tryingto incorporate a component-based approach to systematise 1 Corresponding author,  ricardo.sanz@upm.es 2 This work was funded by the European Commission through grantIST-004669 COMPARE. software development. This is mostly notable given thatthe traditional engineering approach to developing embed-ded applications has been driven by the primary goal of maximizing performance whilst absorbing the minimumof resources like memory or power consumption. Thisconventional approach is usually adopted by compromis-ing software engineering productivity desiderata, such asreusability or maintainability, sacrificing modularizationto achieve reduced size and/or complexity.However, even in the most constrained class of embeddedapplications —as those designed for deployment on DSPdevices— software processes are supported by toolchainsbased on component models that are usually tailored tosuch devices.This paper describes the technological products of the ISTCOMPARE project funded by the European CommissionIST Programme. The main objective of the COMPAREproject was the provision of models and technology tofulfill real-time requirements in component-based, real-time embedded applications (RT/E). The approach of COMPARE that makes a bigger difference from otherreal-time component models like Pecos, ACCORD, AOCS,OBS (e.g. et al. (2002)) is the focus on standardisation of the technology following an open process.2. EMBEDDED COMPONENTS LANDSCAPEOne seemingly unavoidalbe trend in software for real-time embedded systems is towards complexity. This raisingcomplexity is due to the increased functionality these sys-tems are required to to provide in an increased uncertaintyenvironment thay may include other interacting systems. Proceedings of the 17th World CongressThe International Federation of Automatic ControlSeoul, Korea, July 6-11, 2008 978-1-1234-7890-2/08/$20.00 © 2008 IFAC689710.3182/20080706-5-KR-1001.3001  Real-time software architectures commonly used in em-bedded systems were primarily meant to fulfil just real-time performance issues and are not suitably structured tosupport this evolutionary increase in complexity. One bigchallenge in complex embedded systems is thus to reframethe design process from a performance-centric approachto a complexity-centric approach, whithout loosing thetemporal performance so critical for these systems.Fig. 1. The ECF Component-Container model for embed-ded real-time systems.This movement toward increased complexity is not exclu-sive of the embedded systems domain but is also happeningin conventional software. Non real-time applications arealso facing this increase in complexity and have producedsome relevant paradigms of interest in the embedded com-munity.The paradigm we are exploring in the work describedin this paper is that of the very promising compo-nent/container model. However current models ( e.g.  Sun’sEJB 3 or OMG’s CCM 4 ) were srcinated and targettedto enterprise information systems. Therefore, the servicesthey specify ( e.g.  persistence or transactions) are notmainstream necessities of real-time and embedded systemsengineering.Perhaps motivated by losing the enterprise role it haddue to HTML-based SOA 5 CORBA-related efforts havemoved towards real-time and embedded areas ( cf.  most of the recent adopted specifications at www.omg.org).The recently adopted Lightweight CCM, CCM-based com-ponent technology has started a move in this very samedirection by defining a minimum profile upon which it isnow possible to build a model dedicated to real-time andembedded.This paper The purpose of this project is to study aframework based on this model (CCM for real-time andembedded), to realise a reference implementation of it, totest it on two different application cases (one based on RT-CORBA, the second on OSEK-VDX RTOS) and to pushthe results at OMG for standardisation. 3 Enterprise Java Beans. 4 CORBA Component Model. 5 Service Oriented Architecture. 3. PROJECT RESULTSThe COMPARE project ended in December 2006 aftertwo years and a half and the results obtained can besummarized in the following five items: •  The definition of a RT/E framework for component-based embedded systems: this framework is calledECF -  Embedded Component Framework  . •  A reference implementation of the ECF based on RT-CORBA [1]. •  A first technology demonstration in the field of Soft-ware Defined Radio [5] built with the CORBA [7]reference implementation. •  A derived partial implementation on OSEK-VDX [2]. •  A second demonstration on the field of ElectricityManagement Systems built with the OSEK-VDXpartial implementation.The global objective of the separation of concerns ap-proach in component-based systems is the segregation of business logic from underlying RT platforms to maximizecomponent reusability. This reusability was demonstratedby the mapping of the general ECF model into two quitedifferent deployment platforms: RT-CORBA and OSEK-VDX.OSEK-VDX and RT-CORBA differ enormously in thelevel of services they provide and hence it is therefore un-realistic to plan to support the full range of functionalitiesas the reference implementation does. The intention is toport to OSEK-VDX all that can be ported at a reasonablecost. Obviously it will comprise, as a minimum, what isneeded to support the related electricity management use-case.4. APPROACHThe main technological goals of this work are three-fold: •  full separation of concerns between system functionsand enabling software platform technologies (middle-ware and RTOS), so as to maximize deployability of reusable components across an heterogeneous plat-form base, •  enabling the use of a variety of architectural styles forembedded systems (including distributed, real-timeand deeply embedded devices) •  facilitate tool-supported construction by interface-level composition of reusable modules following stan-dard component models (see Figure  ?? ).These directions were identified as necessary by a domainanalysis of current common concerns in the domain of real-time and embedded systems design and implementation[3].The separation of concerns between system functions andenabling software technologies aspect is recognized as animportant technological lever to treat portability becausein this approach, the system functions implementation areunderlying technology free.Separation of concerns is also natural in the scope of component orientation, which is all about placing thecomponent as the unit of architectural decomposition:traditional approaches for real-time systems focusing first 17th IFAC World Congress (IFAC'08)Seoul, Korea, July 6-11, 2008 6898    !"#$"%&%' !"%%&!'"(#)'!*+%, $)+( ". &/'&%0&0 $"('1!"#$"%&%'1+#$2& $)+( ". #)'!*+%, $"('1!"#$!"#$!)% 3&) #&#"(4 .("%'+&(5$*41+!)26(&)2+7)'+"% .(),#&%' .(),#&%'!"%%&!'"( 1$&!+.+! !"##8%+!)'+"% 2"!)2!"%%&!'+"%2"!)2!"%%&!'+"% Fig. 2. The ECF is based on a Component/Connector model that enables the definition of the port type needed forspecific interaction models and the connector required for interaction between entities having some extended portsand attributes.on tasks and synchronisation characteristics often resultedin systems shaped by these aspects, implying importantcoupling between systems functions, complex mapping of functions to tasks, and intricate tasks collaboration.Supporting a variety of architectural styles is also impor-tant in the real-time embedded domain, in which fun-damentally different execution models and architectures(most of the time engineering domain oriented) are in-volved. The motivation for putting emphasis on a cleanintegration of custom interaction patterns is to avoid rele-gating these aspects to component programmer themselvesin case the component model would have been foundlimitative. Another key motivation in this regard stemsfrom the fact that intermediate-granularity components(i.e. not too coarse) can reveal the candidates for reuse,and often exhibit between them complex interactions.Tool-supported composition is also important, as compos-ing and configuring complex systems by hand reveals verydifficult and error prone. The basis for the automatedcomposition is an architecture description in the form of acomponent assembly descriptor. Automated compositionis at the heart of component-oriented approaches. It canalso be thought as a particular type of separation of con-cerns, also reducing the complexity to setup and configurea system.The technical approach, in order to achieve the goalsexplained above, is based on extending and profiling theLightweight CCM (LwCCM) specification [4] and COM-PARE contributions come in three forms: •  Integration of new features in the CCM componentmodel and deployment facilities. •  Definition of profiles from Lightweight CCM andOMG deployment and configuration. •  Adaptation of the LwCCM specification: some minorneeds for modification in the specification.5. CORE GUIDELINES OF THE ECF APPROACHComponent-based applications are built by componentinterconnection. Components provide services to othercomponents and require services from other componentsthrough provided (facets) and required ports (receptacles)(see Figure  ?? ). To perform their function, componentsmay use services from the underlying platform (e.g. com-puting or timing events).In order to maximise reusability of component businesslogic the ECF model isolates the component from theexecution platform by means of a container that providesa set of technical services that are used by the component.The ECF implementation is open and extensible and thesetechnical services are provided by means of container-levelpluggable elements [6].Many services are under development in the context of theCOMPARE project in order to provide some basic func-tionality required by the demonstrators. These servicesinclude for example distributed state machines, timers,clock synchronisation, transactional memory, distributedlogging, etc.With this approach the ECF can separate the func-tional aspects provided by the component from the non-functional aspects concerning its use in a particular ap-plication that are provided by the container (see Figure2).Detailed specifications about the framework includingthe proposed extensions to LwCCM specifications areprovided in the framework design documentation from theCOMPARE project [10].6. DEVELOPMENT PROCESSThe development process proposed by COMPARE andoutlined outlined in Figure  ??  is obviously focused oncomponent-based reuse, separating the engineering activ-ity in three major phases:(1) Production of components(2) Application design(3) Component deploymentThe developed approach not only focuses on an optimisedand fully modular realisation of the needed software fea-tures, but also to a development process enjoying thefollowing properties: 17th IFAC World Congress (IFAC'08)Seoul, Korea, July 6-11, 2008 6899    !"#$"%& ()&"*+ ,- *&./-+0 ./01 2*3+*&%&)4%5-&-)-*& 12#/3*&456./&6&2,",1-2*&4#)1.,1-2732#,1-2"/*&4#)1.,1-2 812")+91/&   6%'7-8% 2*&5-9:'()-*& ;-<%=  #6.2"6&: 9"#&,2"6&: -.&)",1-22"6&; <<< =&)>1#&/18 ?&>&/-.&) 16./&6&2,",1-2 2*3+*&%&)-3+<%3%&)()-*& 34&4   @A&#3,-)4 (BBC 4,"2*")* 12,&)9"#&40 BDEFG 4.&#191# 12,&)9"#&4 ; 12,&)#&.,1-2 #"// 12 ,H& 4.&#191&* -.&)",1-2; %&2&)1# -.&)",1-2 9-) 4&)>1#& 124,"//",1-2 22> ?'(++%', @9%&%'()%4 +(') *5 )A% 2*&)(-&%'B 61#)-BBC %&2&)",-)  ./0 .&)%'5(8%, (2&&*&* ,- *&912& #-6.-2&2, .-),40 BDEFG=,384I=$&/   DEF 5?J;#-6.1/&) %&2&)",-)  !"#$"%& ()&"*+ ,- *&./-+0   !"#$"%& ()&"*+ ,- *&./-+0 ./01 2*3+*&%&)4%5-&-)-*& 12#/3*&4   ./01 2*3+*&%&)4%5-&-)-*& 12#/3*&456./&6&2,",1-2*&4#)1.,1-2732#,1-2"/*&4#)1.,1-2   56./&6&2,",1-2*&4#)1.,1-2732#,1-2"/*&4#)1.,1-2 812")+91/&   812")+91/& 6%'7-8% 2*&5-9:'()-*& ;-<%=  #6.2"6&: 9"#&,2"6&: -.&)",1-22"6&; <<< =&)>1#&/18 ?&>&/-.&) 16./&6&2,",1-2 2*3+*&%&)-3+<%3%&)()-*& 34&4?&>&/-.&)   16./&6&2,",1-2 2*3+*&%&)-3+<%3%&)()-*& 34&4   2*3+*&%&)-3+<%3%&)()-*& 34&4 @A&#3,-)4 (BBC 4,"2*")* 12,&)9"#&40 BDEFG 4.&#191# 12,&)9"#&4 ; 12,&)#&.,1-2 #"// 12 ,H& 4.&#191&* -.&)",1-2; %&2&)1# -.&)",1-2 9-) 4&)>1#& 124,"//",1-2 22> ?'(++%', @9%&%'()%4 +(') *5 )A% 2*&)(-&%'B   @A&#3,-)4 (BBC 4,"2*")* 12,&)9"#&40 BDEFG 4.&#191# 12,&)9"#&4 ; 12,&)#&.,1-2 #"// 12 ,H& 4.&#191&* -.&)",1-2; %&2&)1# -.&)",1-2 9-) 4&)>1#& 124,"//",1-2 22> ?'(++%', @9%&%'()%4 +(') *5 )A% 2*&)(-&%'B 61#)-BBC %&2&)",-)  ./0 .&)%'5(8%, (2&&*&* ,- *&912& #-6.-2&2, .-),40   ./0 .&)%'5(8%, (2&&*&* ,- *&912& #-6.-2&2, .-),40 BDEFG=,384I=$&/BDEFG=,384I=$&/ DEF 5?J;#-6.1/&) %&2&)",-)  Fig. 3. The ECF engineering process for embedded real-time systems. •  traceability of the software architecture (descriptionof the breakdown of the application into components)all along the development process, •  separation of concerns in the implementation phase:realising the decided execution semantic on an RTOSor middleware platform, versus implementing andcapitalising on domain functional blocks integratablein fundamentally different target platforms in a guar-anteed a priori manner, •  ease and agility in the final integration phase of thesystem, by allowing to relocate lately componentsfrom one device to another.A critical aspect in this engineering process is componentselection (see Figure  ?? ).The current implementation of the Embedded Compo-nent Framework includes software for infrastructure andcontainers — the latter comprising building support(toolchain) and the provision of various component ad-ministration functions.The testbed employed in the development of the ECF andthe evaluation of its real-time properties is comprised of a General Purpose Processor (GPP) and a Digital SignalProcessor (DSP) device. They represent the hardware usedas part of the signal processing chain of a Software DefinedRadio (SDR), one of the demonstrators of the project.The application software is built following a functionaldecomposition of an SDR waveform, represented as gen-erated components, and distributed across the GPP andDSP devices using the ECF framework.The framework hence shows the following capabilities of the component architecture, •  Support for the composition of an application bythe assembly and deployment of components ontoresource-constrained devices. •  Realize a real-time capability by use of the COM-PARE component execution environment and theunderlying real-time Operating System (RTOS) andappropriate middleware infrastructure for distributedcommunications. •  Demonstrate a level of adaptability such that compo-nents can be developed for diverse platform RTOS,communications data transport, and programminglanguages.7. ADVANTAGES OF THE ECF TECHNOLOGYThe advantages of using component-based technology inthe RT/E domain, are founded in the core architectureof the component model, and are realized using variousdevelopment and productivity tools specifically adaptedto this class of application. Portability  : RT/E applications are developed for a widediversity of operating systems (OS) and hardware plat-forms. One commonly adopted approach to providingmore portable solutions is to incorporate an applicationlayer that abstracts the required underlying platformfunctionality. Unfortunately, this approach presents par-ticular difficulties when defining an API having commonsemantics across widely diverse architectures, and itmay be the case that useful (often proprietary) functionsneeded to support a particular business goal may beunavailable on some supported platforms. The com-plexity of the abstraction layer will also increase withthe diversity of platform support required, therefore thesolution will not scale well when introducing new OS andhardware variants. The core abstractions in the compo-nent model on the other hand, provides the opportunity 17th IFAC World Congress (IFAC'08)Seoul, Korea, July 6-11, 2008 6900  to develop specialized (fit-for-purpose) containers, andallows the re-deployment of components from one RT/Edevice to another without the need for source-code mod-ification. Reusability  : The reuse of software units within thescope of an organisation or collaborating parties is apractice known to increase cost-effectiveness in softwaredevelopment (see Figure  ?? ). However, in order to ex-ploit such advantages, an appropriate level of granular-ity is necessary for the decomposition of application codeinto re-usable units needs to be identified. In an ObjectOriented programming model, difficulties can arise dueto the assumption that different entities in a softwaresystem/archive have interfaces that are amenable to in-heritance and aggregation — also that these are writtenusing the same programming language. Thus, connect-ing large numbers of relatively homogeneous units usingspecialised coding conventions and styles can be error-prone and expensive. In a component model, formal defi-nitions strengthen the visibility of component dependen-cies and therefore enforce rules for application assembly.This has the overall effect of minimizing ambiguity whenselecting software units for re-use, thereby increasingcost-effectiveness in development, and reducing time-to-market. Separation of Concerns  : In conventional software de-velopment, there is often an inherent need to understandthe broader issues associated with non-functional sys-tems - enabling technologies, software integration, globalsystem architecture etc. Domain experts therefore, canrarely invest their energy exclusively into the designdevelopment of business solutions. This problem is alsoexacerbated where the complexity of non-functional sys-tems increases — as is the case with RT/E applications.Here, detailed (specialist) knowledge of non-functionalsystems is tightly coupled with application developmentconcerns. The separation of concerns evident in theCOMPARE approach provides the opportunity for do-main experts to focus exclusively on the design devel-opment of business solutions, resulting in a more cost-effective use of development resources. Visibility  : Software development practices that re-usein-house coding styles — naming conventions, layout,modularization, and language specific productivity tech-niques, make it difficult for external parties to engage incollaborative development projects. Where new prod-ucts are developed, this situation would likely impact toa greater extent on time-to-market. In a standards-basedcomponent model, coding styles/patterns are formallyspecified - usually public domain. This arrangementfosters cleaner integration and encourages closer part-nerships between collaborating parties. Quality in Development  : When the use of conven-tional programming leads to the creation of monolithicsystems, additional complexity is introduced into testingand validation systems. Consequently, these are rela-tively expensive to produce and are often not re-usable.The de-composition in component-model architectures,allows software units (components) to be naturally iso-lated for testing and validation. This provides the oppor-tunity to adopt an evolutionary approach to test devel-opment that can be integrated throughout the softwaredevelopment life cycle. Quality in Production:  Strategies for self-managementthat ensure high system availability can be applied moresystematically using components than with other moreconventional systems. A component could for example,validate that an input value is within an acceptablerange and provide a response that is non-intrusive tothe component. Similar self-management strategies canimprove system reliability by safeguarding componentintegrity in production.8. A NOT SO SIMPLE EXAMPLEMartinez [11] demonstrates the advantages of the ECFapproach in the implementation of a component-basedsimple —demonstration-class— adaptive controller.The extended component technology provided by theCOMPARE ECF makes possible the minimally intrusiveinterception of component calls to exploit the access tocall/return values for the implementation of added func-tionality to preexisting systems.Using this approach only latency and jitter are introduced;there maximizing reusability as there is no need of com-ponent code instrumentation. This makes possible the useof this container-level interception technology for exter-nally sourced, binary distributed components (or even forthe reuse on non-compoanes-based controller implementa-tions).This transparent access to interaction flows can be usedfor component introspection or reflection, hence increasingthe flexibility and reusability of of the codebase by meansof standardised design patterns.a) ControllerSensor ActuatorIdentificator ContainerContainer b)Fig. 4. A block diagram (a) of a simple adaptivecontroller to be built using three ECF compo-nents ( controller, sensor and actuator  ) and acontainer-pluggable service ( the identificator  ).In (b) we can see a component diagram of the three ECF components and the container-pluggable service ( the identificator  ) that usescontainer level interception to perform non-intrusive control system monitorisation.The simple adaptive controller of this example [11] usesthree full-fledged real-time ECF components:  controller, 17th IFAC World Congress (IFAC'08)Seoul, Korea, July 6-11, 2008 6901
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks