METHODOLOGY PRESENTATION

SPECIFICATION PEARL© Roman Gumzej,Maribor (2001 – 2004)METHODOLOGY PRESENTATIONPEARL is a standard programming language [PEARL81, PEARL82], developed for programming real time systems. It is one of the rare programming languages allowing the programmer to use times explicitly to specify the start time of an activity or to limit its duration. The standard implementation of the language still supports the functional programming paradigm and modular programming. There have been several attempts to make an object- oriented version of the language [FRI97], which only enhanced the standard types definition. Classes have been implemented by extending the module concept. Another approach to object orientation of PEARL was provided in [VER99], which extended the syntax of the language considering the TASK as a type class and enabling single inheritance. This implementation was also associated with a schedulability analyser.Because contemporary automation demands include the programming of distributed, error prone multiprocessor systems, it was decided by the developers of PEARL to enhance it for multiprocessor systems. In PEARL for distributed systems the language was enhanced with constructs enabling the abstract description of the HW and SW architecture of systems. They enable the co-specification (co-design in some extent) of real-time systems, hence increasing their coherence and reliability. The instructions of this extension of PEARL are not translated into assembly language like “normal” PEARL code. Instead they act as instructions for systems programs (e.g.: compilers, configuration managers, loaders, etc.).The properties of the specification language are the following:•Constructs for the description of HW configurations,•Constructs for the description of SW configurations,•Constructs for the description of communications and their properties (peripheral and inter-process connections, physical and logical connections, data transfer protocols), and•Constructs for the specification of conditions and methods for the execution of dynamical reconfigurations in failure conditions.The standard Multiprocessor PEARL language was enhanced in [GUM99] for the description of station components with their most characteristic and timing parameters, which are also meant to serve as input for the parameterisation of a schedulability analyser. Additional types of stations have been introduced for the description of asymmetrical architectures. They have been assigned parameters for the parameterisation of CM/RTOS. A methodology for the co-specification and feasibility checking of the produced designs has been developed. The associated CASE tool enabling code production and co-simulation of the designs has been built. The name of the methodology is Specification PEARL and is abbreviated as SPEARL.SPECIFICATION LANGUAGEThe architecture description in Specification PEARL syntax is composed of sections of specification code, which describe in detail the different associated levels of the designed system: STATION DIVISION, CONFIGURATION DIVISION, NET DIVISION and SYSTEM DIVISION.HW configurationIn the STATION DIVISION the processing nodes (i.e.: stations) with their most important properties are introduced. On this level they are treated as grey boxes with connections among them. The detailed properties of stations are gathered by setting the properties of their components, namely their processors (PROCTYPE), working storage (WORKSTORE) and integrated devices (DEVICE). Every station in the system architecture has its unique ID, the ID of its super-station if it is a part of it, the description of its components, the type of the station, determining its role in a distributed system, as well as its state information.Several types of stations have been introduced. The BASIC station denotes a general-purpose RTOS-less processing unit. To be able to describe asymmetrical architectures two additional types of stations have been defined: TASK for pure application task processors and KERNEL for the (application and) RTOS (kernel) processors. To be able to describe hierarchical architectures a COMPOSITE station was introduced as a super-station consisting of one or more stations. Its substations are defined by specifying the super-station in their PART OF attribute. Hence, multiprocessor nodes are introduced rather by composition of single-processor (PROCTYPE) nodes than by introducing more than one PROCTYPE in a station. Considering the type of the station they may have additional parameters. The KERNEL station has attributes for the parameterisation of the RTOS: scheduling strategy ID, maximum number of tasks, synchronisers, external events and events in the event queue, real-time clock resolution, etc. On the other side the TASK station also has its associated KERNEL station specified.On each station’s component level their stations components are described by their properties. They are assigned unique ID-s, for which (on preference) one can also use the manufacturers ID-s or descriptions for easier comprehension.Processors (PROCTYPE) are assigned a speed description (clock frequency). It is possible to have multiple processors in a single station, whereas a separate station should be introduced if the second processor is not connected to the same bus. In this case a multiprocessor node is better represented by two interconnected stations within a super-station.The working storage (WORKSTORE) is described by the size and allocation of individual memory areas. It is possible to specify the access time to these areas and their type (on-chip RAM, RAM, ROM usually have different access times). This information can be used by the compiler to assign the memory space correctly to programs and data and to optimise the access time. The RAM and ROM memory areas can be modelled separately since they usually have different purposes. One can specify more than one memory area for each, but their address spaces shall not overlap.The specification of integrated devices attributes (DEVICE) is meant primarily to parameterise their drivers since they mainly represent memory-mapped devices. One can specify the address or the name of the driver. Since most devices represent I/O lines connection points INTERFACE-s have been introduced beside general devices. Here one can also specify the , address and control registers, transfer kind (package or DMA) and speed. Because of the great diversity of these devices it doesn’t make sense to describe them in greatdetail. In case of “standard devices”, whose properties could be obtained from a database, only their unique name or ID may be specified.For completeness reasons the bandwidth of the BUS must be specified for each station.NET DIVISION describes the topology of the HW architecture by specifying connections between pairs of stations’ components (INTERFACES). By specifying point-to-point connections any topology can be described. In addition to connection points the connection directions are specified.In the SYSTEM DIVISION of a PEARL program the HW devices, being addressed in the PROBLEM DIVISION of the program are assigned logical names for easier reference. In Specification PEARL this description is enhanced with connections from the NET DIVISION.SW configurationThe CONFIGURATION DIVISION represents the program configuration. The biggest program part, which can be associated with a station is the COLLECTION. It is composed of MODULES of TASKS. For their inter-communication PORTS are used. PORTS are global with respect to the COLLECTION and are visible from the outside. They are addressed by a combination of the name of the COLLECTION and the PORT name.The MODULES which encapsulate TASKS are described by their names and interfaces (IMPORT, EXPORT definitions).The TASKS are defined by specifying their response times. They are additionally defined by two attributes: (1) “initial” , which denotes an initial task – the task which starts the execution of the collection and activates or schedules any additional tasks and (2) “keep”, which denotes a “critical” task – a task, which is not pre-empted in case of an overload situation. Their semantics and trigger conditions are defined by their associated TSTD (Timed State Transition Diagram) diagrams.The COLLECTIONS are loaded to the specified STATION. It is possible to define the state of the station, associated with each COLLECTION. These conditions refer to the state of the STATION and inform its configuration management program (CM) on how to perform the dynamic reconfiguration operations.The associations of states with the collections may have different purposes and depend on the application. They can be considered phases of a complex procedure, where the individual operations can be separated by their time of occurrence safely. The states can also represent the global state of the system or its parts, where the initial state represents the start-up operations on each node after which the station is transferred to the operating state in which it remains until an exceptional event changes its state. Based on the cause of the state change and provided one can foresee them a corresponding reaction (dedicated COLLECTION) can be assigned the task to handle the situation and bring the station into operating or safe shutdown state.The PORTS of the collection are described by the direction of data flow and the attributes of the connection. In case HW connections (specified in the NET division) are meant, the described HW connection, which serves the communication among ports, can be specified by the VIA connection specification. In case there are more possibilities, the preferred connection can be specified by the PREFER attribute (then it is up to the CM to chose the first available connection line).Every PORT, physical or logical, can be assigned a protocol, which is used for the communication, and any additional signals may be specified. The following protocols have been predefined: No-Wait-Send, Blocking-Send, Send-Reply.In the standard multiprocessor PEARL the most common signals, representing the expected communication errors have been defined. They have been adopted in Specification PEARL: CONNECT_ERROR : If upon entering the TRANSMIT or RECEIVE operations the corresponding PORT to PORT connection is non-existent this signal is raised and the operation is aborted.BUFFER_ERROR : If on using the No-Wait-Send protocol some message could not be transferred because of the buffer was full, this signal is raised, and the TRANSMIT operation is aborted. The recipient is also informed – if this error occurs before the end of the RECEIVE operation, this signal is raised and the operation is aborted.TRANSMISSION_ERROR : transmission errors (noise or time frame delays, etc. ) raise this signal. It is raised in both – the sender and recipient side and the corresponding transfer operations are aborted. The current message is considered not transferred.REPLY_ERROR : On an error upon receiving the answer with the Send-Reply protocol (noise or time frame delay, etc.) this signal is raised. It is raised in both – the sender and recipient sides and the corresponding transfer operations are aborted. The current message is considered not transferred.GRAPHICAL SPEARLBeside the textual Specification PEARL syntax, described in Appendix A, also the corresponding graphical notation was devised. It was used in the mentioned CASE tool. It is described in detail in Appendix B.While choosing the graphical symbols we have followed the following guidelines:• A common form for each component group.•Symbols can be identified and differentiated among themselves easily.•Specialised components' symbols are added some décor to differentiate them from other components of the same group.•Within the tool by double-clicking the form or right-clicking it enables the designer to reach its components or properties respectively.In addition to the textual Specification PEARL the graphical form also contains the description of TASK semantics in form of TSTD diagrams. They represent PEARL program TASKS and the output from the tool produces (PEARL) program prototypes from the diagrams. The semantics of TSTD diagrams together with the description of their translation to PEARL program code is given in Appendix E.acknowledgementsThe Multiprocessor PEARL standard has two forms:1.Basic form, combined with a RTOS and targeted on single processor applications and2.Full form, combined with a configuration manager (CM) and inherent RTOS istargeted on distributed applications.They have been adopted in the Specification PEARL language implementation, but without a firm boundary between them.The main differences between the two forms are in the scope of their applications:1.The Basic form:•STATION DIVISION: definition of a single station;•NET DIVISION: empty;•SYSTEM DIVISION: assignment of logical names to device names of the station;•CONFIGURATION DIVISION: collection definition, initial loading, the description of logical interconnections;•Message interchange: logical PORT specifications; 1->n, n->1 communication through PORTS.2.The Full form has the properties of the basic form with the following additional features:•STATION DIVISION: definition of multi-processor stations, distributed and hierarchical architectures and description of their state information with theassociated system services;•NET DIVISION: HW connection lines among stations;•SYSTEM DIVISION: assignment of logical names to device names and connection lines;•CONFIGURATION DIVISION: the mapping of logical to physical connections (VIA, PREFER) and specification of dynamical reconfiguration;•Message interchange: logical and physical PORT specifications; 1->n, n->1 communication through PORTS.RTOSThe SPEARL reference implementation is primarily PEARL oriented also in its system services. In the tool the corresponding RTOS, supporting the PEARL process model (Figure1) and system calls is included. The detailed description of the RTOS API with the implementation of system services is described in Appendix C . The RTOS is part of the CM (Configuration Management) module, described below.Figure 1: PEARL RTOS process modelFor a detailed description of the RTOS kernel, please refer to (Colnaric et. al. 1998). Legend : A - task activation T - task terminationE - normal task endS - task suspensionC - task continuationL - LOCK operation(failed)U - UNLOCK operationSCH - SchedulerActivestatesCMCM (Configuration Manager) is the shell (initial loader and monitor) for the COLLECTIONS, executing on each station. It must be loaded on each station regardless of the simultaneous presence of the RTOS on the same station. Its role is to perform the initial configuration and any subsequent dynamic reconfiguration operations. It also services any message exchange commands. The CM must be aware of the type of the STATION in order to service or root the messages correctly. Hence, the messages must be encoded accordingly. In general each message is a literal (first byte contains the message length, while the following bytes contain data).The functionality as well as the API of the CM are presented in detail in Appendix D.The main loop for CM operation is the following:BeginInitialization of the configurations and connectionsLoad the collections of the initial configurationLoopMonitor the ports and service the messages and interrupt requestsService the CM / RTOS requestsM onitor the state of the station and act accordinglyEnd loopEndSPECIFICATIONS INTERPRETATIONThe specification code in SPEARL syntax can be used as input data for:•compilers; enabling the target HW aware compilation (processor type, memory amount, etc.),•schedulability analysers; with the timing information (processor speeds, memory access times, interface speeds, etc.). The more data are provided, the more reliable are its results, although the most reliable results are obtained by measurements on the target platform.•loaders; CM is provided information on the mapping of SW parts to HW stations. The memory space can be checked before downloading the programs and data. A configuration manager is also able to reload parts of code and replace them in concordance with the specifications in case the state of the station changes in the foreseen manner. Since by this feature the safety and reliability of operation is addressed, the utilisation of a configuration manager introduces a controlled change (temporally and spatially) to perform a “quick” and “predictable” switch to “plan B”.The current implementation produces annotated C code for feasibility estimation by co-simulation and compilation for the target platform. More on the implementation level specifications is given in Appendixes F, G and H below.LIMITATIONS ON THE DESIGNS AND SIMULATIONStations:- multiprocessor stations are modelled by compositions of single-processor stations;- each station may have one processing unit, one bus and one or more I/O devices, which determine the number of possible I/O lines with other stations;- station state is an integer in the range of one byte (0-255), the initial state is numbered »0«;Collections:- each collection can only be associated with one state of a single station;- it can possess one or more ports for communication with other collections, which are associated with the corresponding stations' lines; each port may use one or more linesas the only possible (VIA attribute) or preferential (PREFER attribute);- since there are other possibilities for information exchange within the collection, ports are used for message interchange among collections at different stations;Tasks:- belong to one module / collection;- their interfaces are stored in module definition files (hence, they must include their headers);- for co-simulation the code of the task is executed as part of the »SimulacijskiKorak« procedure of the Task simulation unit; in the code there are calls to »DolociCasNaslednjega« to determine the time of the next critical event for »SimulacijskiKorak« of this task.Global naming conventions apply for PORTS, SIGNALS and SEMAPHORES. Their names and parameters are stored in the A-data (Appendix H) of the configuration manager. To address them, one must always specify the name of the corresponding collection with their name.APPENDIXESAppendix A – Textual Specification PEARL syntaxAppendix B – Graphical Specification PEARL syntaxAppendix C – RTOS API specificationAppendix D – CMM API specificationAppendix E – TSTD to source code translation specification Appendix F – Simulator descriptionAppendix G – PEARL RTOS / CM system call encoding Appendix H – Configuration files for CM / RTOS parameterisationREFERENCES1.01 Original scientific article1. COLNARIČ, Matjaž, VERBER, Domen, GUMZEJ, Roman, HALANG, Wolfgang A.Implementation of hard real-time embedded control systems. Real-time syst., May 1998, 14, št. 3, str. 293-310. [COBISS.SI-ID 3622422]2. GUMZEJ, Roman, VERBER, Domen, COLNARIČ, Matjaž, BABAU, Jean-Philippe,SKUBICH, Jacques J. An experiment in design and analysis of real-time applications.CIT. J. Comput. Inf. Technol., Sep. 2000, vol. 8, no. 3, str. 181-195. [COBISS.SI-ID5830934]3. GUMZEJ, Roman, COLNARIČ, Matjaž. Specification PEARL constructs for embeddedreal-time systems co-design. PEARL-News, nov. 2002, ausg. 2, str. 5-10. http://www.real-time. de/news/news02-2.pdf. [COBISS.SI-ID 7543574]1.08 Published scientific conference paper4. GUMZEJ, Roman, COLNARIČ, Matjaž, VERBER, Domen, HALANG, Wolfgang A.Towards standard-based specification and design of embedded real-time systems. V: Proceedings of the 24th Euromicro Conference, Västeras, Sweden, August 25-27, 1998.Proceedings. Los Alamitos: IEEE Compuetr Society, 1998, str. 453-460. [COBISS.SI-ID 3878166]5. GUMZEJ, Roman, COLNARIČ, Matjaž, BABAU, J.-P., SKUBICH, J. Hardwarearchitecture components for real-time systems design. V: ZAJC, Baldomir (ur.). Zbornik sedme Elektrotehniške in računalniške konference ERK '98, 24. - 26. september 1998, Portorož, Slovenija. Ljubljana: IEEE Region 8, Slovenska sekcija IEEE, 1998, zv. A, str.41-44. [COBISS.SI-ID 3958038]6. BABAU, J. Ph., COLNARIČ, Matjaž, CONTRERAS, R., GUMZEJ, Roman, SKUBICH, J.,VERBER, Domen. Execution model for real-time server object. V: Proceedings of the IEEE International Symposium on Industrial Electronics - ISIE '99, Bled - Slovenija, July12 - 16, 1999. Piscataway: IEEE Service Center, cop. 1999, vol 1, str. 70-74.[COBISS.SI-ID 4688406]7. GUMZEJ, Roman, COLNARIČ, Matjaž. An approach to real-time systems co-design andverification. V: HAMZA, M. H. (ur.). Proceedings of the IASTED international conference Control and applications (CA'2000), May 24-27, 2000, Cancún, Mexico. Anaheim;Calgary; Zürich: IASTED/ACTA Press, 2000, str. 327-333. [COBISS.SI-ID 5575702]8. GUMZEJ, Roman, COLNARIČ, Matjaž, HALANG, Wolfgang A. An approach toembedded hard real-time systems co-design. V: SANCHEZ, Belkis (ur.). WorldMulticonference on Systemics, Cybernetics and Informatics, July 23-26, 2000, Orlando, Florida. Proceedings. Vol. 2, Information systems development. Orlando: International Institute of Informatics and Systemics, 2000, str. 62-67. [COBISS.SI-ID 5585942]9. GUMZEJ, Roman, COLNARIČ, Matjaž. HW/SW components for real-time systems co-design. V: KALPIĆ, Damir (ur.), HLJUZ DOBRIĆ, Vesna (ur.). 23rd Internationalconference on information technology interfaces, Pula, Croatia, June 19-22, 2001. ITI 2001 : proceedings of the 23rd international conference on information technologyinterfaces, Pula, Croatia, June 19-22, 2001. Zagreb: SRCE - University ComputingCentre, University of Zagreb, 2001, str. 455-460. [COBISS.SI-ID 6349334]10. GUMZEJ, Roman, COLNARIČ, Matjaž. An approach to modeling and verification of real-time systems. V: Proceedings : ISORC 2001, 2-4 May 2001, Magdeburg - Germany. Los Alamitos [etc.]: IEEE Computer Society, 2001, str. 283-290. [COBISS.SI-ID 6191382] 11. GUMZEJ, Roman, HALANG, Wolfgang A. PEARL for distributed embedded systems:object oriented perspective. V: KLEINJOHANN, Bernd (ur.). Design and analysis ofdistributed embedded systems. Boston: Kluwer Academic Publishers, cop. 2002, str. 11-20. [COBISS.SI-ID 7338774]12. GUMZEJ, Roman, HALANG, Wolfgang A. A configuration manager for embedded real-time applications. V: Co-design for embedded real-time systems (CERTS'03). [S. l.]: The IEE, 2003, 6 str. [COBISS.SI-ID 8096022]13. GUMZEJ, Roman, COLNARIČ, Matjaž. The representation of PEARL tasks as timedstate transition diagrams. V: COLNARIČ, Matjaž (ur.), ADAMSKI, Marian (ur.),WĘGRZYN, Marek (ur.). 27th IFAC/IFIP/IEEE Workshop on real time programming,WRTP'03, May 14-17, 2003, Łagów (Poland). Preprints. Zielona Góra: University, Institute of computer engineering & electronics, 2003, str. 97-102. [COBISS.SI-ID 7926294]2.08 Doctoral dissertation14. GUMZEJ, Roman. Embedded Systems Architecture Co-Design and its Validation :doctoral thesis. Maribor: [R. Gumzej], 1999. III, 97 f., graf. prikazi. [COBISS.SI-ID4873238]。