Institut Supérieur de l Aéronautique et de l Espace AADL Generative Implementation Annex Jérôme Hugues, ISAE
Key question answered by the annex How to implement a subprogram, and bind it to an AADL model? page 2
Scope of the annex document > Traceability back to the AADL requirement document (ARD 5296): Validate and Generate complex systems > Scope of the annex» Define the user interface to the AADL runtime» Allow for efficiency expected by users > Outside the scope: usage of RTOS resources» Do not mandate an implementation Mapping of AADL threads onto RTOS threads Use of synchronization primitives for event ports, Use of memory for buffering page 3
Current status > Latest draft submitted in January 2013» Written up to 90%» Need to clarify the mapping of AADL runtime services > Implementation prototype available as part of Ocarina, for both C and Ada» Targeting regular RTOS, and ARINC653 > Also similar effort is implemented through the RAMSES plug-in by Telecom ParisTech» More up-to-date to ARINC653» Support also OSEK runtimes (automotive domain) page 4
Outline of the annex document 1. Naming conventions» Mapping of AADL identifiers onto target language identifiers» Mapping of AADL packages 2. Mapping of data types» Link with the Data Modeling Annex document 3. Mapping of AADL subprograms» Variations given AADL modeling patterns 4. Using the AADL runtime services > Use of a basic flight management system to cover most situations defined in the annex document page 5
1. Naming convention > Mostly mapping rules of AADL identifiers to source code» Rationale: avoid naming collisions with keyword, etc.» Derived from CORBA IDL mapping specifications > Ada language». must be replaced by underscores _.» Two consecutive underscores must be replaced by _U_.» AADL_ prefix for identifiers that clash with an Ada keyword. > C language» (C RM 6.4.2.1), identifiers derived from AADL are lowercase.» aadl_ prefix for identifiers that clash with a C keyword.» Additional rules for collision with underlying C API (RTOS, ) page 6
Mapping of AADL packages > Ada language» Hierarchy of AADL packages are mapped onto an equivalent hierarchy of Ada packages. E.g. foo::bar is mapped onto package foo.bar > C language» AADL hierarchy is mapped onto a single name, where dots are placed with two consecutive underscores. E.g. Foo::Bar is mapped onto Foo Bar page 7
2. Mapping of data types > The Data Modeling Annex is defining precise semantics for all property values for basic types: size, (un)signed» Map to the corresponding language type» Proposed mapping for types from Base_Types package All kind of integers, float, etc. as a reference > Composite types (arrays, records, ) are given detailed mapping rules, following examples from the annex document» See A.5.3 for details» Note that arrays, records have two possible modeling patterns Need to support both page 8
3. Mapping of subprograms > Rely on CORBA IDL mapping specifications for mapping AADL subprograms to equivalent C or Ada code > Follow parameters names, in/out, etc > Yet, it depends on the actual usage of the source program» Are we defining an AADL model for a library E.g. subprogram groups?» Or the subprogram to be executed in a thread? page 9
3. Mapping of subprograms > Different modeling patterns may occur» Both ports connect to parameters as part of a call sequence entrypoint» A thread has a Compute_Entrypoint T: T.impl T: T.impl» In port connected to subprogram parameter T: T.impl T: T.impl» Subprogram attached to a port page 10
3. Mapping of subprograms: easy part > Different modeling patterns may occur» Both ports connect to parameters as part of a call sequence entrypoint T: T.impl T: T.impl 1.» Have A thread the runtime has a Compute_Entrypoint call the user subprogram with corresponding value or 2. User call the AADL runtime T: T.impl» In port connected to subprogram parameter (1) Implemented in Ocarina, easy solution for integrating legacy code, or code generated from 3 rd part tools T: T.impl» Subprogram attached to a port page 11
3. Mapping of subprograms: tricky part > Different modeling patterns may occur These» Both patterns ports require connect visibility to parameters on the AADL runtime for T: T.impl manipulating port variables as part of a call sequence entrypoint» A thread has a Compute_Entrypoint T: T.impl» In port connected to subprogram parameter T: T.impl» Subprogram attached to a port T: T.impl page 12
3. Mapping of subprograms: other considerations > Two instances of the same thread» Same features, compute entrypoint» Need to distinguish at runtime level Ports variables, access, subcomponents, P.impl 5ms 5ms T1: T.impl T2: T.impl > Solution:» Introduce an instance specific context record» Gives access to all internals and externals visible in this particular context» Passed as parameters to code executed by the userprovided code page 13
Context for subprograms > Concept borrowed from CORBA CCM» Widely used in many component-oriented frameworks > Context give access to all entities visible from the subprogram perspective» User-code hosted by a thread» Thread component type has visibility on Features, data, subprograms, > Similar syntax used to dereference all elements» Features: self.<port>» Data: self.<data>» Subprograms: self.<spg> page 14
Context for subprograms (cont d) thread Landing_Gear_T features Dummy_In : in event port {Compute_Entrypoint_Source_Text => on_dummy_in";}; end Landing_Gear_T; void on_dummy_in( aadl_ctx *self) { aadl_send_output (self->landing_gear_local_ack,&request); } > This self parameter would be used by the AADL runtime to route the request to proper destination > Resolution: no need to say more about aadl_ctx type, it is up 1. to this the context code generator info need to to be define passed it, and in all instantiate cases to be it > Options consistent, and reduce code adaptation Or» this context info need to be passed in all cases to be 2. Property consistent, set for and specifying reduce code whether adaptation we want context info passed or not: Code_Generation_Pragmas::Convention => (AADL legacy); page 15
Modeling patterns for accessors > Is there an agreement on the following pattern? > Update is an accessor» Requires access to data» One instance part of data» Connected to particular members subprogram Update features this : requires data access POS.Impl; value : in out parameter POS_Internal_Type; end Update; subprogram implementation Update.Impl end Update.Impl; data POS features Update : provides subprogram access Update.Impl; end POS; Resolution: YES/NO? Resolution#2: Do we need access to Get/Release_Resourc e? data implementation POS.Impl subcomponents spgupdate : subprogram Update.Impl; Field : data POS_Internal_Type; connections Cnx_Pos_1 : subprogram access SpgUpdate -> Update; end POS.Impl; page 16
The trouble with AADL runtime services > Those are loosely defined > Many parts implementation defined, cannot follow the proposed mapping» Notion of exception» Useless parameters > Would also impact the core of the standard Resolution: suppress AADL signature from the core, keep only the semantics being defined as abstract functions, not AADL subprograms page 17
Extending runtime services > Issue: need of specific device drivers» Rely on implemented_as property to pass additional components (threads, subprograms, buffers,..)» How can a device driver thread send events to other threads? Resolution: extend AADL context type to the process level Add another level Producer of indirection Comm. Dev BUS Consummer aadl_send_output (ctx->thread->port, (void *)data); Get_Parent_Context new runtime service to fetch context handle CPU1 CPU2 Comm. Dev page 18
Semantics of runtime services > AADL runtime services may send «exception» > Issue: what does it mean? Resolution: An exception means an error is triggered, corresponding error handler called Get_Error_Code service can be called from within handler, return a value for the corresponding enumerator, e.g. NoValue page 19
Handling ports and ports queues > Issue: AADL services are implementation-defined subprogram Send_Output features OutputPorts: in parameter <implementation-dependent port list>; -- List of ports whose output is transferred SendException: out event data; -- exception if send fails to complete end Send_Output; > Issue#1: why would someone put a value in a port variable, but not send it? What is the rationale? > Add helper routines: Set_Send (self.<port>);» Dual of the Updated runtime-service, use Updated?» Then call Send_Output, parameter-less, procedure? page 20
AADL guidelines for code generation 1. Avoid X_Source_Text properties» Issue: have to guess actual implementation language» Prefer classifier-based properties Define language, source_name, source_text in a clear way Resolution: suggested additional legality rules 1. Connect the ports?» Default is that all ports must be connected. Required_connection property applied to feature Property to relax this rule on a per connection basis» Shall we relax this rule for subprograms in threads? No resolution? impacts AADLv2.1 core (!) page 21
Advanced topics: prototypes > Shall we define rules about prototypes?» we may allow subprograms with prototypes to have user-provided implementation e.g. C++ template, Ada generic, even some limited support in C» no need for code generated: simply generate the instantiated subprogram Does the instantiation process trashes the prototype? Resolution: additional legality rules only allows for limited types of prototypes: type parameterization, Ada style Avoid subprogram passed as prototypes page 22
Last tricky construct: modes > About modes» If explicitly modeled using port communication, we rely on standard mechanisms» What about runtime services? What is implementation-specific? Actual representation? Way to name modes? subprogram Current_System_M ode features M odeid: out parameter <i mpl ement or-specific>; -- I D of t he mode end Current_System_M ode; Resolution: additional legality rules User needs not worry about modes: simply provides different entrypoint, one per mode page 23
Roadmap > Have resolution for all issues for end of March > Final document for the April meeting page 24