See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220280646 Engineering software reuse for on‐board embedded real‐time systems ARTICLE in SOFTWARE PRACTICE AND EXPERIENCE · MARCH 2002 Impact Factor: 0.9 · DOI: 10.1002/spe.436 · Source: DBLP CITATIONS READS 7 24 2 AUTHORS, INCLUDING: Tullio Vardanega University of Padova 126 PUBLICATIONS 696 CITATIONS SEE PROFILE Available from: Tullio Vardanega Retrieved on: 03 February 2016 Engineering software reuse for on-board embedded real-time systems ☎✝✆ Tullio Vardanega , ✄✁ ✂ Gert Caspersen ✞ ✟ European Space Research and Technology Centre, Keplerlaan 1, 2200 AG Noordwijk, NL Terma, Bregnerodvej 144, 3460 Birkerod, DK SUMMARY The dimensions of concern to ambitious reuse initiatives largely exceed the provision of desired functionalities. A domain-specific blend of functional, technical and quality considerations determines the reuse potential of software reuse assets. In a recent project we realised considerable reuse dividends from coupling the definition of a reference software architecture and of an associated set of standard interfaces with the selection of a powerful computational model equipped with reuse-geared enabling technology. In this paper we present our engineering approach to the project and show how it earned us a good balance between the preservation of predictability and scalability and the maximisation of the reuse objective. KEY WORDS : Software reuse; reuse metrics; concurrency; Ravenscar profile; generic instantiation; object model. INTRODUCTION The consolidation of the engineering research into software reuse (cf. e.g.: [26, 25]) has recently penetrated the space business and prompted the question whether and how can reuse lower the rising development cost of new-generation software-intensive on-board systems. The question is relevant for at least two good reasons. On the one hand, environment characteristics and mission requirements curtail the productivity of space software projects for on-board application in comparison to other business sectors (cf. e.g.: [24]) and make them ill-equipped to meet increasing user demands without incurring serious cost overruns. On the other hand, the only practical opportunity for the development of software systems for on-board application to respond to the new business climate, which goes under the name of ‘cheaper, faster, better’, will be to attain a considerable productivity ✠ Correspondence to: the new address of the author, who is presently with the University of Padua, Dept. of Applied Mathematics, via ✡ G. Belzoni 7, 35131 Padova (Italy). ☛ E-mail: tullio.vardanega@math.unipd.it E-mail: gec@terma.com ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 1 increase. By way of example, earlier work [30] anticipated the software productivity demand to quadruple in the next few years, for twice as big software to be delivered in half the time, within no less than the present envelope of dependability. Software reuse is a useful response to the challenge. It may increase the dependability of the product via defect removal from the reuse baseline. It may also increase productivity by way of work avoidance. Work avoidance alone however is only a contributing factor to the achievement of the overall productivity objective [4]. Other complementary process means and engineering techniques have to contribute to it, too. This cautionary observation is necessary to stop unrealistic expectations (and, thus, unjustified disappointments) being placed on the ultimate yield of reuse. In this paper we discuss the engineering characteristics of a software reuse framework specifically designed for new-generation on-board systems. We first lay down the methodological foundation to our work. We then illustrate the strategic, architectural and technological choices that most characterise our development. Subsequently, we examine a representative cross section of our implementation approach. Finally, we evaluate the performance of our software product with respect to predictability and sizing, which are crucial concerns to our application domain, and reuse ratio, which is the chief objective of our initiative. BACKGROUND Arguably, the definition and the enforcement of standard specifications is a most effective means to facilitate effective reuse within and across industry. A standard specification named Packet Utilisation Standard [18] (PUS for short) has recently emerged at the European Space Agency to address a significant proportion of the recurrent data handling and control functions on board their satellite systems. Although originally intended to prescribe the application-level protocol for ground to on-board communications, the standard effectively embodies a vast amount of reuse potential for the on-board system also; primarily by way of promoting a domain-specific descriptive model and a domain-specific architecture of the system (in the way advocated, for example, by [19]). The PUS definitions form the specific domain of the reuse initiative discussed in this paper. A serious software reuse initiative needs an effective software development process to support it. Earlier work [29, 30] argued that an iterative and incremental development process is better equipped than the traditional ‘waterfall’ model to cope with the increasing complexity of the on-board software product and the concurrent reduction of the development schedule. The process vision we subscribe to calls for a software architecture scalable enough to accommodate successive increments and also capable of assuring the integrity of the system and the convergence of the process. Three major ingredients are essential facilitators to a reuse-centric realisation of this process of ours: (a) an application model that favours the scalability of the system and promotes a reference architecture, which leads to ‘reuse by architecture’; (b) a software reuse framework that accelerates the construction of systems in accord with the application model and its reference architecture, which allows ‘reuse by artifacts’ and requires attention for both the static and the dynamic aspects of the system; (c) enabling technology that supports the production of reusable, reliable and predictable software, which permits ‘reuse by technology’. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 2 TULLIO VARDANEGA, GERT CASPERSEN To seize the opportunity presented by the emergence of the PUS, the European Space Agency funded the development of OBOSS (short for: on-board operations support software) [27], a library of reusable software components along with a domain-specific architecture for their utilisation, designed for the construction of on-board data handling systems compliant with the standard. The programmatic objective of OBOSS is to constitute a vehicle for inter-company ‘open’ software reuse as well as a model for intra-company ‘proprietary’ reuse. The OBOSS concept effectively builds upon specific instances of the process facilitators mentioned above. The OBOSS notion of software reuse in fact encompasses: a reference architecture that matches the PUS application model (corresponding to reuse by architecture) a set of software components with standard interfaces and prescribed operation semantics, organised in what we call a software reuse framework (corresponding to the static facet of reuse by artifacts) a predictable and scalable computational model (corresponding to the dynamic facet of reuse by artifacts) a specific reuse strategy that optimally uses the selected language support (corresponding to reuse by technology). We will return to each of these aspects in the following section and later in the paper. A CASE FOR SOFTWARE REUSE Application Model Satellite systems typically perform their operation under the supervision of a control centre based on ground. The ground centre exercises its authority on the on-board system by the issue of telecommands (TC) and the reception of status and verification information contained in the response telemetries (TM) returned by the satellite. The servicing of the TC/TM flow between the ground centre and the orbiting satellite constitutes one fundamental function of the real-time software embedded in the spacecraft controller, the single platform component that integrates together all of the control and service functions performed on board. The set of communication-related activities associated with the servicing of the TC/TM flow is collectively termed Data Handling and Control (DHC) system. The European Space Agency’s Packet Telemetry and Packet Telecommand Standards [17, 16] and the CCSDS Recommendations from which they are derived [9, 10] address the end-to-end transport of TC and TM data between user applications on ground and the respective destination and sources on board and, accordingly, prescribe the general layout of TC and TM packets. The PUS [18] complements and extends those standards by defining a packet-based protocol for the transmission and on-board distribution of TC, and a standard set of monitoring and control services to be performed on board. The PUS defines those standard services by prescribing the service model, i.e., the manner in which service providers are to behave on the arrival of service requests, and the inner structure of the TC and TM packets carrying respectively service requests and the corresponding service reports. The purpose of the standard was to cover the known requirements of present and future space missions while staying open to the introduction of additional services and service capabilities as the Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 3 need arises. One interesting corollary of the openness of the standard is that the vast majority of individual services are defined independently of one another, so that the execution of any one of them would not involve the execution of any other. The notion of service capability denotes the possible use of the service as prescribed by the standard, which may entail mandatory and optional elements. The definition of the PUS is thus the product of a very comprehensive domain analysis performed over a broad spectrum of missions and, consequently, also an especially suitable basis for the construction of software reuse libraries for on-board and on-ground utilisation. In the context of the PUS, the on-board entities that are capable of receiving TC packets and of generating TM packets are referred to as ‘application processes’. From the standpoint of the ground operator, therefore, application processes are service providers and specific entities of the ground centre(s) are service users. A natural extension to this model, however, allows application processes to also issue service requests, which the ground issues encoded as TC packets. Application processes would in this case become true peers to service users on ground and therefore interchangeable with them. This extension entails simple modifications to the outer structure of standard TC and TM packets and is essential to autonomous systems where the supervisory capabilities traditionally placed on ground are delegated to application processes on board. An application process is uniquely and statically identified for the entire lifetime of a mission. No restrictions are placed on the mapping between application processes and the usual functional subdivision of a satellite into subsystems and payloads. Accordingly, application processes may operate as centralised providers of monitoring and control services or as dispatching agents for remote subsystems equipped with own processing capabilities. As a by-product of prescribing the protocol for the transmission and distribution of TC and the associated service model, the PUS evokes the notion of a PUS-based on-board architecture, and a particularly loosely-coupled one at that. The fact that TC carry service requests that are directed to application processes determines an implicit relationship of containment between application processes and a corresponding set of service capabilities. An application process may embed any number of service capabilities, in the nature and quantity required to operate on the section of the space segment specifically assigned to it. The loosely-coupled nature of the PUS on-board software architecture directly follows from this relationship of containment: a service request addressed to one application process does not perturb the activity (or the quiescence) of any other application process. Figure 1 depicts the top-level architecture that emanates from this interpretation of the PUS. The figure maps the abstract view of a PUS-based space system onto the traditional model. The components of the former are, at times, service users and / or service providers. In the latter, instead, application processes are service providers, ground centres are service users, TC embed service requests and TM embed service reports. The notions entailed by the PUS model extend the potential coverage of a software reuse initiative from a scattered collection of utilities and functions to a library of architectural elements and service modules. Reference Architecture Several key features of a PUS-compliant DHC software architecture emanate directly from the conceptual model shown in figure 1. First and foremost, the bulk of the software infrastructure in charge of on-board communications that adhere to the standard may stay largely the same across missions, Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 4 TULLIO VARDANEGA, GERT CASPERSEN Data Handling and Control System Local Subsystem Service Provider 1 Application Process 1 service Service Request Service Report Ground Centre 1 Telecommand Service Request Service User 1 Application Process i service Service Provider j capability set 1 On-board Traffic Management capability set i Service Report Telecommand On-board Traffic Management Telemetry Telemetry Ground Centre k Service User N service capability set n Remote Subsystem Service Provider m Application Process n Space Segment PUS abstract view of a space system. Ground Segment PUS abstract view mapped to a traditional space system. Figure 1. Views of PUS-based architecture of a space system. with regard to both the structure and the interpretation of packets. Furthermore, the loosely-coupled character of the PUS architecture and the event-driven nature of the associated service model (with the event being the arrival of a service request) imply that the processing of independent commands may proceed in parallel throughout the system as a whole as well as within individual application processes. Consequently, the software architecture of application processes themselves naturally break down to two major components: a recurrent infrastructure for the support of the routing and the interpretation of service requests and service reports within and among application processes; and an applicationspecific collection of standard service capabilities to be embedded within the individual application processes. OBOSS provides configurable support for packet-based message passing between the ground segment and on-board application processes and for the servicing of the relevant commands. The system architecture promoted by OBOSS proceeds directly from the reference model depicted in figure 1 and, as its model, it is loosely-coupled and inherently scalable. Control flow within OBOSS is predominantly event-driven, with an event corresponding to the arrival of a packet-encoded message from any source in the system, whether ground or on-board based. Two forms of communications take place within a PUS system, and thus within OBOSS. The communication between application processes is packet based. The communication within application processes is also packet based as long as it involves a local destination, while it relies on user-supported protocols for all communications that involve remote destinations. Remote destinations that feature own control processing capabilities are termed subsystems. Remote destinations that do not possess those capabilities are called units. The packet-based communication architecture within OBOSS is centred around a Packet Router that distributes packet-encoded messages to the mailbox of the destination application processes. OBOSS provides each application process with a local Packet Dispatcher that fetches the packet from the local mailbox and delivers it to the service capability concerned. OBOSS allows DHC-based application processes to operate as communication agents for on-board subsystems that are physically disjoint from the DHC. In that case, the application process resident on the DHC embeds no service capability and simply forwards packets to and from the remote subsystem, Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 5 service capability set OBOSS−based DHC Subystem Application Process 1 Application Process i Service 1i Application Process n Service Service i1 ij Packet Dispatcher Packet Depositor Packet Dispatcher Packet Depositor Service nj Packet Dispatcher Packet Depositor Remote Subsystem On−board Bus Interface Packet Router Ground Interface System Infrastructure Platform Services Remote Unit Runtime Support Space Segment Telecommand Telemetry Ground Segment Figure 2. Structure of an OBOSS-based system. which operates as the actual service provider (or service user). OBOSS preserves the locality of its packet-based communication infrastructure by providing fully reusable components to interface agents to the Packet Router. The most obvious instance of OBOSS agent represents the ground centre that operates the spacecraft. Another typical instance of OBOSS agent occurs in systems comprising payload instruments equipped with their own control computers. The OBOSS agent in this case would operate as the local communication proxy for the remote control unit of the corresponding payload instrument. The instrument control unit itself would in this case embed the whole service capability set of the application process. Application Process in figure 1 and in figure 2 illustrates this notion by comprising an OBOSS agent on the DHC platform and a service capability set on the remote subsystem. Figure 2 depicts the main architectural components of a software system based on OBOSS. (The reader should notice the structural match of the OBOSS architecture in figure 2 with the abstract system model shown on the right side of figure 1.) The box tagged ‘On-board Traffic Management’ in figure 1 logically corresponds to the boxes tagged ‘System Infrastructure’ and ‘Platform Services’ in figure 2. The System Infrastructure component carries out the hardware-independent packet handling and the Platform Services component encapsulates all dependencies from the specific physical communication network on board. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 6 TULLIO VARDANEGA, GERT CASPERSEN The OBOSS reuse framework provides a catalog of software components that fully support the system infrastructure. User-supplied components that conform to the OBOSS static and dynamic interfaces are instead required to complete the implementation of the platform services. Software Reuse Framework The OBOSS reuse model enforces the adoption of the reference architecture depicted in figure 2 and of the communications infrastructure associated with it. To this end, the OBOSS reuse assets comprise: (i) a set of generic units for constructing application processes; (ii) a set of generic units embedding service capabilities that cover a subset of those specified in the PUS; (iii) a vast amount of guidance information for the construction of mission-specific DHC systems. Two subsequent stages of domain analysis (cf. [13] and [14]) determined the core of PUS services most suited for software reuse. Two key criteria guided the selection of services and service capabilities: (i) the likelihood of use in future missions, whereby a service frequently used would constitute a natural reuse candidate; (ii) the cost of instantiation for a mission, whereby a service specification that allows for a design with low instantiation cost (i.e., that is with significantly more recurrent code than what it would need to make an instantiation) would be a valuable candidate for reuse. Ref. [18] defines 17 standard service types, each uniquely identified by an index in the range [1..17]. Domain analysis identified 9 of those standard services for OBOSS to support. Of those, 2 correspond to the TC verification service and the event reporting service, which are intrinsic (and compulsory) to the very essence of PUS application process. All other 15 standard services are optional in the sense that a PUS system may provide any subset and any combination of them. Overall, the standard allows for a total of 256 service type identifiers. Those in the range [18..127] are reserved for future additions to the standard set. Those in the range [128..256] are free for the user to define in an application-specific fashion. The view held by the authors of the cited domain analysis is that the OBOSS selection of service ✂✁☎✄ of the typical PUS coverage of new-generation on-board systems. capabilities covers up to The notion of generic unit constitutes the building block to the OBOSS architecture. In languageneutral terms, a generic unit is a template that factors out commonalities in the treatment of abstract actions or data structures, which are associated to generic formal parameters. Correspondingly, a generic instantiation is a copy of the generic unit that provides a concrete definition for those actions and data structures, in the form of generic actual parameters. A specific concurrent behaviour may be associated to the execution of a generic instantiation simply by (logically) embedding the generic instantiation defining that behaviour within the corresponding generic unit. In this way, the concurrent behaviour of an outer generic instantiation in OBOSS becomes a permanent attribute of the corresponding generic unit. The inner unit that determines that behaviour is not under the direct control of the user, who can only define selected configuration parameters of the embedded concurrent unit, such as execution priority and stack size. As a reflection of this strategy, the core of an OBOSS-based system is constructed by assembling together a battery of generic instantiations, a collection of adapted templates and a set of interface procedures. Figure 3 explodes the view of the OBOSS internal architecture by zooming into the inner structure of an application process ✆ embedding an instance of PUS service capability ✝ . In keeping with its approach to reuse, OBOSS implements PUS service capabilities as a hierarchical collection of generic Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS Application Process i connectors (exploded view) 7 terminals Packet Dispatcher Packet Router Packet Depositor Service ij Bus Terminal On-board Bus Interface Application Process Parameters System Infrastructure legend: Platform Services OBOSS component for unmodified reuse OBOSS template for user adaptation attributes user-supplied component ✝ Figure 3. Exploded view of an application process. units. The polygon tagged ‘Service ij’ in figure 3 represents the outermost generic instance for service in application process . Parameter configuration is the primary means offered by OBOSS to control how reuse assets group together into a coherent system architecture. As highlighted in figure 3, the OBOSS parameters belong in three main categories: ‘connectors’, which attach individual application components to the OBOSS system infrastructure; ‘attributes’, which capture specific functional characteristics of the individual component; and ‘terminals, which encapsulate dependencies on the physical architecture of the system in the OBOSS interface to user-supplied platform services. ‘Connector’ parameters interface the application process to the mailbox-based message passing system of OBOSS. The OBOSS reuse model provides templates for how the terminal interface requirements should be met. Those connectors effectively correspond to the user adaptation of a standard set of mailbox-based Send Packet, Receive Packet and Deposit template procedures, which OBOSS employs to transport packet-encoded messages to destination. The boxes tagged Packet Dispatcher and Packet Depositor in figure 3 represent the ‘connector’ parameters of application process . Packet Dispatcher implements the outermost Send Packet-based interface to the application process. Its implementation will reflect the nature and the topology of the service components embedded within the application process, each of which will provide the implementation of a Receive Packet-based entry point. Packet Depositor deposits packet-encoded service reports produced by the application process in the mailbox of Packet Router, which forwards them to the intended destination. ✆ ✆ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 8 TULLIO VARDANEGA, GERT CASPERSEN ‘Attribute’ parameters define the configurable characteristics of the specific application process or the specific service incarnation within it (e.g.: unique identifier of the application process, service policy, service priority). The component tagged ‘Application Process Parameters’ in figure 3 represents the attributes emanating from the application process to the service incarnation in this instance. ‘Terminal’ parameters interface the application process to remote destinations that logically belong to it. Those destinations are termed subsystems when they possess own control capabilities or else units when they do not. In the former case, OBOSS only provides for the communication agent to the remote subsystem and the ‘terminal’ parameter is the means that transports packet-encoded messages to and from the agent. In the latter case, the ‘terminal’ parameter is used to enable the monitoring and control capabilities embedded within the local service incarnations to acquire values from and send commands to the relevant unit. In order to maximise the symmetry of its user interfaces, OBOSS uses a pair of Send / Receive nonsuspending subprograms for the implementation of all its ‘terminal’ parameters. It is the responsibility of the user to supply a non-suspending body that conforms to the OBOSS specification. The dashed box tagged Platform Services in figure 3 globally represents all of the ‘terminals’ needed by an OBOSSbased system, along with their interface counterpart within application processes. The component tagged Bus Terminal in the same figure represents an instance of ‘terminal’ parameter that interfaces the application process and its service incarnation(s) to the controlled remote unit via a given on-board bus interface. We shall return to these architectural notions later in this paper, when we illustrate the way OBOSS implements a selection of them. Enabling Technology On-board systems are inherently concurrent. A large proportion of new-generation systems will be even more so on account of the integration of an increasing number of control functions on a decreasing number of processing nodes. Our need is, thus, for a computational model that facilitates the controlled expression of that inherent concurrency. Our choice originates from the definitions given in HRT-HOOD [7, 8] and relies on the principles of fixed priority preemptive scheduling [2, 3]. HRT-HOOD extends the base HOOD design method [21] in use at the European Space Agency by incorporating the abstractions supported by the revised tasking model of Ada 95 [23] in the fashion prescribed by the Ravenscar Profile [5]. Our computational model allows for: periodic objects to model time-triggered threaded activities; sporadic objects to model event-triggered threaded activities, for which the triggering event is either a physical interrupt or a software synchronisation; and protected objects to model non-threaded structures for data-oriented synchronisation. The Ravenscar Profile represents the most compact and efficient set of language primitives needed to implement our computational model. Architectures built in accordance with our computational model and implemented using the Ravenscar Profile lend themselves to static timing analysis. Ref. [30] describes a set of static analysis techniques that support this notion. The Ravenscar Profile [5] defines a subset of the Ada 95 language that aims at predictable and efficient use of concurrency in high-integrity real-time systems. The definition of the profile especially seeks: Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 9 Staticness of task and protected objects, and of priority assignments throughout the system. The profile excludes both the use of such objects and types other than at library level and the use of dynamic priority assignments at run-time. Monotonic time and absolute delays for a more accurate generation of time-based events. The profile excludes the use of the coarse-grained Calendar package and of relative delays. Simplified mechanisms for inter-task communication centred on the use of asynchronous communication via protected objects, with the corresponding simplification of run-time behaviour. The profile excludes the use of rendez-vous based synchronous communication (hence task entries and select statements), asynchronous task control, abort statements and termination in general. Minimisation of blocking conditions by restricting protected objects to have at most one entry with a simple boolean barrier and a single caller. The tasking model that emanates from the Ravenscar Profile is particularly restrictive in terms of what it excludes of the wealth of tasking constructs supported by the language definition. Yet the profile is powerful enough to express a plausible implementation of the cyclic, sporadic and protected objects defined by HRT-HOOD, which are among the main ingredients of the OBOSS concept. The prime motivation behind the definition of the Ravenscar Profile was the quest for memory size and execution time efficiency, predictability and verifiability. This notion made an especially compelling argument for OBOSS to consider, for OBOSS addresses an application domain constantly seeking those characteristics. OBOSS faced two major challenges in the decision to shape its concurrency model in accord with the Ravenscar Profile. The first challenge was to express this concurrency in a manner that would fit in the OBOSS design philosophy. The second challenge was to determine what drawbacks and limitations, if any, would arise for an OBOSS-based system from the restrictions imposed by the profile. An interesting question indirectly raised by the OBOSS initiative is whether the Ravenscar Profile is sufficient for the construction of a complete on-board system of the new generation. This paper and associated earlier work (cf. e.g.: [28]) provide some, arguably solid, evidence to this effect. As a direct consequences of these design decisions, OBOSS is entirely coded in Ada [22, 23] and is designed for direct execution on embedded Ada runtimes, so as to minimise dependence on external interfaces. No special requirements are placed on the implementation of the user-supplied components that are expected to co-exist with OBOSS in an operational system, except for those that directly interface with it, from which OBOSS requires static and dynamic conformance with a specific interface profile. Two consolidated features of the Ada language proved an excellent match for distinguishing characteristics of the OBOSS architecture: (A) generic units as the main vehicle for software reuse; (B) embedded tasking in the way of the Ravenscar Profile for increased predictability and portability to embedded platforms. The first implementation of OBOSS completed in 1997 [11], before mature Ada 95 technology, with its support for object orientation, was available for target platforms of interest to the project (cf. e.g.: [15]). As a reflection of this origin, OBOSS is an Ada 95 system as regards the concurrency model, but a pure Ada 83 system in the respect of its sequential component. In keeping with the capabilities of Ada 83, the OBOSS objects have structure, state and operations but lack true inheritance Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 10 TULLIO VARDANEGA, GERT CASPERSEN (specialisation) and polymorphism, which are the distinguishing characters of full object orientation. In spite of this limitation and of the lack of an explicit ‘class’ keyword in the language, OBOSS objects are created by generic instantiation of base entities that we will call classes. OBOSS classes (and the corresponding objects) are made active by embedding the required type of concurrency within them. The emergence of the Ravenscar Profile in 1997 [5] and of associated supporting products (e.g.: [12, 1]) permitted the OBOSS project team to revisit implementation choices made for its concurrency model. OBOSS 2nd generation [27] originated as the team’s response to these stimuli. All references to OBOSS in the remainder of this paper specifically denote OBOSS 2nd generation. IMPLEMENTATION Having looked into the design-level aspects of our engineering approach, we may now turn our attention to the concrete decisions we have made in the implementation of the OBOSS software reuse framework. In particular, we concentrate on the inner structure of the application process that we outlined earlier in figure 3. The application process represents the major component of an OBOSS system and it is the key to its intrinsic scalability. The discussion that follows will also implicitly illustrate the way OBOSS enforces standard interfaces with prescribed operation semantics and the way this also caters for a predictable and scalable computational model. Before going any further, however, we need to introduce the taxonomy of components that populate the OBOSS software reuse framework. The OBOSS reusable software components belong in three main categories: (i) class objects , implemented as the instantiation of generic units; (ii) template objects, implemented as model library units, which the user must tailor (i.e., source edit) to suit the specific needs of the system; and (iii) auxiliary objects, which OBOSS uses for the definition of class and template objects, and that the user need not access. OBOSS objects in any of these three categories are either active or protected or passive in the way HRT-HOOD defines these notions. Class objects and auxiliary objects may give ✁ ✁☎✄ rise to unmodified reuse, whereas template objects primarily serve as structural guidance to the implementation. Passive objects at the top of an implementation hierarchy are composite (i.e., parent) objects the implementation of which needs child objects of passive type only. Active objects at the top of the hierarchy are composite objects that are implemented by at least one active terminal object. Child objects may in turn be parent or terminal. Terminal objects have no child. Passive terminal objects do not possess an own thread of control and their methods (called exported operations in HOOD parlance) are executed by the calling thread of control. Active terminal objects possess their own thread of control, which may be either cyclic or sporadic. Sporadic objects are further subdivided into interrupt sporadic and software sporadic depending on the nature of their triggering event. Cyclic terminal objects provide no methods for other objects to invoke, hence they only invoke the methods of others. Software sporadic terminal objects provide one single method (notionally named Start) which other ✁ ✡ Recall that we use the notion of ‘class’ in a loose sense: an OBOSS class may be freely instantiated, thus becoming a (class) object, but it cannot be extended. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 11 HRT-HOOD object type (I=interrupt sporadic | S=software sporadic | C=cyclic | Pr=protected | P=passive) Object Name Use relationship Exported operation set Generic instantiation of thread object Generic instantiation of composite object Thread Instance : <task type> Object Instance : Generic Object Generic Actual Parameters Generic Actual Parameters Set of generic actual parameters including: task operation Figure 4. Descriptive notations. (Dashed lines attach explanatory text to notations.) objects invoke to trigger the sporadic operation of the object. For interrupt sporadic terminal objects, the corresponding method is assumed attached to the corresponding interrupt source and accordingly invoked. The Start method is asynchronous in that it returns immediately after delivering the intended execution request to the mailbox of the designated service object. Active objects that provide methods other than Start have them implemented by child objects that are either passive or protected. Protected objects provide methods that warrant synchronous and mutually exclusive execution. Figure 4 shows the HRT-HOOD graphical notations that we use to describe the internal architecture of an OBOSS system. OBOSS Units of Concurrency The structure of the active terminal objects in OBOSS rigorously conform to the prescriptions of the Ravenscar Profile. The most natural way for OBOSS to factor out this structural conformance is to represent sporadic, cyclic and protected terminal objects as classes. In this manner, individual active terminal objects are simply obtained by generic instantiation of the corresponding class. To illustrate the approach, in the following we present the implementation of the classes whose instantiation makes up a software sporadic terminal object. The requirement that software sporadic terminal objects provide one single method named Start fully determines the specification of the corresponding generic unit, which is shown in figure 5. OBOSS active components communicate by message passing, as a reflection of which the parameter of the Start operation is expected to be a packet-encoded message with a variable inner structure. The parameter type determines the type of the incoming message, that is, the inner structure of the corresponding packet. The sporadic operation of the task (Operation) takes a parameter of the same type as the Start operation, which allows the former to operate on the incoming message. The arrival Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 12 TULLIO VARDANEGA, GERT CASPERSEN ✁ ✁ auxiliary definitions including: with Priority Control; system-specific priority definition generic configuration parameters including: Task Priority : in Priority Control.Active Task Priority; static priority of task size of task stack Task Stack Size : in Natural; Event Buffer Priority : in Priority Control.Protected Priority; ceiling priority of event buffer Event Buffer Size : in Positive := . . . ; size of event buffer (preset default) type Parameter Type is private; with procedure Operation (Parameter : in Parameter Type); sporadic operation package Sporadic Task is function Start (Parameter : Parameter Type) return Boolean; end Sporadic Task; ✁ ✁ ✁ ✂ ✄ ✁ 5 ✁ ✁ 10 Figure 5. OBOSS implementation of sporadic task class (specification). of the message defines the triggering event for the sporadic task (and consequently makes it software sporadic). Figure 6 shows the implementation of the sporadic task class. It is worth noting that the OBOSS implementation allows for the occurrence of exceptions and performs some standard handling on them. Owing, in part, to limitations with the language support in use and to design decisions, the current OBOSS implementation ties the exception handling policy at this level to the specific OBOSS build. Future OBOSS upgrades may look into whether and how such a policy could be rendered more easily configurable. The Start operation, which HRT-HOOD wants asynchronous and non-suspending, simply posts the message in a dedicated event buffer. OBOSS factors out the definition of this buffer too, and implements it as an auxiliary class protected object. Every instantiation of a software sporadic task will have its own event buffer with a given size (Event Buffer Size) and a given ceiling priority (Event Buffer Priority). Figure 7 shows the implementation of the class Queue, from which the protected terminal object Event Buffer is derived. This implementation determines the type of data-oriented synchronisation model in place between the caller of the Start operation and the sporadic task itself. In the current implementation, the Start operation is non-suspending even on full buffer while the Extract operation suspends the caller indefinitely on empty buffer. Yet again, both the implementation of the queue data structure and that of the Deposit and Extract operations are presently fixed for any specific OBOSS build. Typical choices for the insertion and extraction policy are FIFO or priority based. All building blocks of this kind sit at the bottom of the OBOSS reuse hierarchy and correspond ✁✂✁ ✄ to auxiliary objects in the taxonomy introduced earlier. As such, they represent instances of unmodified reuse. All the configuration parameters (‘attributes’, ‘terminals’ and ‘connectors’ as shown in figure 3) they need to operate with would descend down to this level, and to all other intermediate levels concerned, from a user specification provided at the outermost level of the OBOSS system. ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS ✁ ✁ 13 useful definitions including: with Queue; auxiliary class object for event buffer with System Clock; interface to system clock package body Sporadic Task is package Event Buffer is new Queue = Parameter Type, (Element Type Queue Size = Event Buffer Size, Queue Priority = Event Buffer Priority); function Start (Parameter : Parameter Type) return Boolean is begin return Event Buffer.Deposit (Parameter); end Start; task Sporadic Task is pragma Priority (Task Priority); pragma Storage Size (Task Stack Size); end Sporadic Task; task body Sporadic Task is Due Event : Parameter Type; configurable by user-level parameters Activation Time : Ada.Real Time.Time := . . . begin to ensure orderly task activation after elaboration delay until Activation Time; loop Due Event := Event Buffer.Extract; Operation (Due Event); end loop; exception appropriate handling when . . . end Sporadic Task; end Sporadic Task; ✁ ✄ ✄ 5 ✄ ✂ ✁ ✄ ✁ ✁ Figure 6. OBOSS implementation of sporadic task class (body). Application Process Breakdown View The notion of application process is absolutely central to our interpretation of the PUS model. The OBOSS design of the application process confers it the modularity, the loose-coupling and the composeability that make PUS systems inherently scalable. An OBOSS application process is built up by composition and configuration of reuse modules according to a recurrent design pattern. We illustrate this constructive approach focusing on a selected sample of reuse modules. Figure 8 displays the details of the breakdown that we shall present to this end. At the top of the application process hierarchy we find a very simple interface specification, which we show in figure 9. Our implementation defines the Send Packet operation exported by the object in terms of an operation with the same profile exported by a child object. This process of encapsulation reflects the HOOD hierarchical decomposition approach. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 10 15 20 25 14 TULLIO VARDANEGA, GERT CASPERSEN ✁ with . . . auxiliary definitions generic type Element Type is private; Queue Size : in Natural; Queue Priority : in Priority Control.Protected Priority; package Queue is function Deposit (Elem : in Element Type) return Boolean; function Extract return Element Type; end Queue; 5 10 package body Queue is protected Queue is pragma Priority (Queue Priority); procedure Deposit (Elem : in Element Type; Response : out Boolean); the boolean response of Deposit lets the sender balk on full buffer entry Extract (Elem : out Element Type); the receiver blocks indefinitely on empty buffer private implementation details ... end Queue; function Deposit (Elem : in Element Type) return Boolean is Response : Boolean; begin Queue.Deposit (Elem, Response); return Response; end Deposit; function Extract return Element Type is Elem : Element Type; begin Queue.Extract (Elem); return Elem; end Extract; implementation details end Queue; ✁ ✁ 15 ✁ 20 25 30 ✁ Figure 7. OBOSS implementation of queue class. Procedure Send Packet represents the sole entry point for incoming service requests destined to the application process. In terms of our earlier taxonomy of OBOSS parameters, this procedure represents a ‘connector’. Child object AP i Packet Dispatcher implements this connector. In this implementation we encounter the first instance of embedded concurrency within OBOSS. The body of the package in figure 10 shows how OBOSS makes objects active by attaching the desired concurrent behaviour to their definition. Also note how OBOSS uses the user package AP i Parameters to hold all the actual parameters (‘attributes’) required to configure the various constituents of Application Process i. A call to Application Process i.Send Packet resolves into a call to the Start operation of the sporadic task TC Forwarder embedded in AP i Packet Dispatcher. We have seen earlier that the implementation of the Start operation entails a transaction on the event buffer embedded within the Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS S 15 Application_Process_i AP_i_Packet_Dispatcher S Send_Packet TC_Forwarder : Sporadic_Task Start Send_Packet Operation => AP_i_TC_Interpreter.Receive_Packet Distribute_Packet : case Destination is P Receive_Packet S AP_i_TC_Interpreter when ... => Application_Process_<>.Send_Packet end case; case Service_Type is when ... => ... when Service_J => AP_i_Service_J.Receive_Packet; end case; AP_i_Service_J : Service_J P Command_Parser : Command_Parser Parse_Command <Command definition parameters> Receive_Packet Execute_Command : case Command_Parser.Parse_Command is when Illegal => Reject_Command; S Command_Interpreter when Legal => Interpret_Command; end case; Receive_Packet Interpreter : Sporadic_Task Start Operation => Execute_Command Interpret_Command : case Service_Subtype is Deposit => AP_i_Packet_Depositor.Deposit P AP_i_Packet_Depositor : Packet_Depositor when <command_id> => <command_exec>; end case; S Deposit Deposit Packet_Router Packet_Forwarder : Sporadic_Task Start Deposit_Response => Packet_Router.Deposit Operation => Distribute_Packet Figure 8. OBOSS architecture of an application process: breakdown of data flow and control structure for command execution and reporting. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 16 TULLIO VARDANEGA, GERT CASPERSEN ✁ with PUS; OBOSS reuse component package Application Process i is procedure Send Packet (Packet : in PUS.PUS Packet); end Application Process i; ✁ for message producers to invoke ✁ 5 to handle incoming messages with AP i Packet Dispatcher package body Application Process i is procedure Send Packet (Packet : in PUS.PUS Packet) is begin AP i Packet Dispatcher.Send Packet (Packet); to start the processing of the incoming message end Send Packet; end Application Process i; ✁ 10 Figure 9. OBOSS implementation of application process template. ✁ with PUS; OBOSS reuse component package AP i Packet Dispatcher is procedure Send Packet (Packet : in PUS.PUS Packet); end AP i Packet Dispatcher; ✁ 5 a number of OBOSS reuse components including: with AP i TC Interpreter; with AP i Parameters; holds all configuration parameters for the application process package body AP i Packet Dispatcher is package TC Forwarder is new Sporadic Task (Task Priority = AP i Parameters.Task Priority, Task Stack Size = AP i Parameters.Task Stack Size, Event Buffer Priority = AP i Parameters.Buffer Priority, Event Buffer Size = AP i Parameters.Buffer Size, Operation = AP i TC Interpreter.Receive Packet, Parameter Type = PUS.PUS Packet, . . . all other parameters); procedure Send Packet (Packet : in PUS.PUS Packet) is begin non-blocking if not TC Forwarder.Start (Packet) then ... error handling on full buffer end if; end Send Packet; end AP i Packet Dispatcher; ✁ ✄ ✄ ✁ ✄ ✄ 10 ✄ ✄ ✁ ✁ Figure 10. OBOSS implementation of packet dispatcher template. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 15 20 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 17 ✁ with PUS; OBOSS reuse component package AP i TC Interpreter is procedure Receive Packet (Packet : in PUS.PUS Packet); end AP i TC Interpreter; ✁ 5 ✁ various OBOSS reuse components including for example: with AP i Service J; instantiation of PUS service J for application process i package body AP i TC Interpreter is to handle erroneous messages procedure Reject Packet (Packet : in PUS.PUS Packet) is ... end Reject Packet; procedure Receive Packet (Packet : in PUS.PUS Packet) is begin case Get Service Type (Packet) is OBOSS reuse service function for as many PUS services as the application process supports, e.g.: when Service J = AP i Service J.Receive Packet (Packet); when others = Reject Packet (Packet); end case; end Receive Packet; end AP i TC Interpreter; ✁ ✁ ✁ ✄ 10 15 ✄ Figure 11. OBOSS implementation of packet interpreter template. sporadic task instance. This choice allows us to fully decouple the message sender from the message receiver, so that the two may effectively proceed in parallel. The implementation of procedure Send Packet lets the sender proceed even in case of full buffer. The implementation traps the failure event without blocking the sender and produces the appropriate response, which typically amounts to a failure report destined to the sender and/or to some supervisory authority. The style that OBOSS has chosen to embed concurrency within objects allows the user to define as generic actual parameters such notions as: the operation that the embedded thread must carry out in response to the triggering event; the priority at which that has to be done; the ceiling priority and, for software sporadic objects only, the size of the associated event buffer. The instantiation of the software sporadic task TC Forwarder typifies the OBOSS approach in this respect. Package AP i TC Interpreter defines the Receive Packet operation of TC Forwarder. This operation multiplexes service requests to the appropriate service provider within the application process. This reflects the delegation of control approach taken by OBOSS, which allows service providers to be implemented as active objects and thus to operate concurrently. All the units we have seen down to this level correspond to template objects in the taxonomy introduced at the top of the section. OBOSS provides models of such units, which the user needs to adapt to the specific characteristics, topology and nomenclature of the system. Only a small proportion ✁✂✁☎✄ unmodified reuse. of this model code will produce instances of One further level down in the OBOSS hierarchy we find the implementation of the PUS service capabilities embedded within the application process. This is where OBOSS pushes its reuse approach ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 20 18 TULLIO VARDANEGA, GERT CASPERSEN to its extreme. As we see from figure 8, AP i Service J is described as an active (software sporadic) object. In HRT-HOOD parlance this means that the object may embed multiple threads the activity of which triggers on a software synchronisation event. Figure 8 shows that the implementation of operation Receive Packet exported by unit AP i Service J involves the concurrent operation of at least one software sporadic task. Several others would also appear at a finer level of decomposition. This implementation approach warrants loose coupling between the message reception mechanism at application level and the execution of the service protocols supported by the application process. The generic unit Service J shown in figure 12 fully defines the structures and operations corresponding to PUS service J and therefore suffices for the implementation of the service instantiation embedded within the application process. Unit AP i Service J still corresponds to a template object, ✁ ✁☎✄ whereas unit Service J represents a base class, which yields unmodified reuse. ‘Terminal’ parameters in OBOSS take the form of Send or Receive subprograms. Specific reuse components invoke these subprograms within the execution of the service protocol concerned. OBOSS however does not employ the invocation of these subprograms as the triggering event of any of its builtin tasks. OBOSS users therefore have to supply non-suspending implementations of these ‘terminal’ subprograms in order for the calling tasks to retain conformance with the Ravenscar Profile, which only allows a single activation event per task. Service components use ‘terminal’ parameters of this kind to acquire values from remote units or to send control commands to them. For reasons of conciseness, we omit showing instances of ‘terminal’ parameters in the code fragments that follow. The instantiation of the formal generic operation Deposit of the Service J class shown in figure 12 is the mandatory ‘connector’ parameter that dispatches the messages produced by the operation of the service object to the Packet Router. Like all PUS services, Service J features a high degree of internal concurrency. As figure 8 shows, the HRT-HOOD connotation of this concurrency is software sporadic. The activity of this object is in fact instigated by the arrival of a service request, which occurs by invocation of the Receive Packet procedure. The implementation of this base class encompasses a considerable amount of recurrent active and passive components. The very same approach taken to the embedding of concurrency in the handling of messages across and within application processes applies to the execution of the specific service protocols. The implementation of operation Receive Packet exported by unit Service J resolves in depositing the service request into the event buffer of Command Interpreter.Interpreter. In turn, the arrival of the service request triggers the activation of the corresponding software sporadic task and the execution of the Execute Command procedure, whose declaration we see in figure 12. In this way, the service execution may proceed in parallel to any other unrelated activities in the system. Individual application processes in OBOSS may embed multiple message producers. Those messages typically contain service reports, which are produced on execution of the Execute Command procedure. All packet-based service reports produced by an application process have to be posted into the mailbox of the Packet Router, which is the sole entity with knowledge of all legal destinations in the system. To this end, a dedicated passive object per application process takes care of the relevant packet collection and dispatching. The base object in charge of this operation (an auxiliary object for our taxonomy) is named Packet Depositor. Figure 13 shows its implementation. ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS ✁ ✁ 19 various OBOSS reuse components including for example: with Service J; corresponding to PUS service J with AP i Packet Depositor; to send response messages package AP i Service J is new Service J ( all required ‘attribute’, ‘connector’ and ‘terminal’ parameters, e.g.: the mandatory connector . . ., Deposit = AP i Packet Depositor.Deposit); end AP i Service J; ✁ ✁ ✄ with . . . generic ✁ 5 a number of OBOSS reuse components ✁ 10 service-specific configuration parameters including: with function Deposit (Packet : in PUS.PUS Packet) return Boolean; package Service J is procedure Receive Packet (Packet : in PUS.PUS Packet); end Service J; 15 ✁ with . . . a number of OBOSS reuse components package body Service J is several instantiations of recurrent support components, including for example: package Command Parser is new Command Parser ( confi guration parameters ); for parsing of messages carrying service requests package Command Interpreter is procedure Receive Packet (Packet : in PUS.PUS Packet); end Command Interpreter; procedure Receive Packet (Packet : in PUS.PUS Packet) is begin Command Interpreter.Receive Packet (Packet); end Receive Packet; package body Command Interpreter is several auxiliary definitions procedure Execute Command (Packet : in PUS.PUS Packet); package Interpreter is new Sporadic Task (Operation = Execute Command, . . .); procedure Receive Packet (Packet : in PUS.PUS Packet) is the caller does not block! begin if not Interpreter.Start (Packet) then ... error handling on full buffer end if; end Receive Packet; end Command Interpreter; end Service J; ✁ ✁ ✂ ✄ 20 25 ✁ 30 ✄ ✁ ✁ 35 40 Figure 12. OBOSS implementation of service class and instantiation template. Obvious reasons of conciseness prevent us from going any further in the illustration of OBOSS implementation. The fraction that we have shown in this section has the least domain-specific characteristics. This selection illustrates a design approach that could arguably apply to any producerconsumer architecture. A large proportion of the OBOSS code that we have not shown here is far more domain-specific. In fact, OBOSS achieves most of its unmodified reuse potential at domain-specific level. It is thanks to the design pattern that we have illustrated above, however, that those domainspecific reuse-intensive modules can fit a scalable and composeable system architecture. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 20 TULLIO VARDANEGA, GERT CASPERSEN ✁ with . . . a number of OBOSS reuse components including: with Packet Depositor; with Packet Router; the system-level message router package AP i Packet Depositor is new Packet Depositor (Deposit Response = Packet Router.Deposit); ✁ ✄ 5 with PUS; generic with function Deposit Response (Packet : PUS.PUS Packet) return Boolean; package Packet Depositor is function Deposit (Packet : PUS.PUS Packet) return Boolean; end Packet Depositor; 10 ✁ a number of OBOSS reuse components with . . . package body Packet Depositor is ... several service operations function Deposit (Packet : PUS.PUS Packet) return Boolean is administration on outgoing Packet return Deposit Response (Packet); which the actual generic parameter attaches to the Deposit operation of the Packet Router end Deposit; end Packet Depositor; ✁ 15 ✁ ✁ Figure 13. OBOSS implementation of packet depositor class and instantiation template. OBOSS Flavours of Object Orientation In our discussion of the OBOSS implementation strategy we have frequently implied the existence of an OBOSS object model of some sort. We now want to better characterise this notion of object with respect to its present and planned extent of object orientation. Concurrent objects typically cooperate by exchange of messages and so do OBOSS objects too. The processing of the message flow produced by concurrent objects may give rise to undesirable interactions. Implementations use various forms of object synchronisation to prevent the occurrence of such events. OBOSS uses synchronisation as the designated means for objects to exchange data. More specifically, OBOSS treats the arrival of an incoming message as the activation event of the destination object. For OBOSS thus we talk of data-oriented synchronisation, which is one particular manifestation of the broader concern of the synchronisation of concurrent objects. The synchronisation of concurrent objects effectively amounts to verifying specific plausibility conditions for the processing of individual messages in a message flow. With Reference [20], we single out three broad categories of synchronisation constraints that determine such conditions: (i) exclusion constraints, which hold when implementation characteristics of the objects concerned inhibit concurrent processing of multiple messages; (ii) state constraints, which hold when the internal state of an object prevents the correct processing of messages; (iii) coordination constraints, which involve the coordination of multiple messages to multiple destinations. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 20 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 21 We talk of server-side synchronisation when the applicable constraints are enforced as part of the message acceptance mechanism of the destination object. Conversely we talk of client-side synchronisation as the constraint is enforced on the sending of the message. In fact, compliance with the Ravenscar Profile only allows server-side synchronisation, for it prescribes inter-task communication to solely occur via the mediation of protected objects, which effectively operate as the server object for both sides of communication. An obvious consequence of demanding the enforcement of synchronisation constraints is that the object behaviour in the event of their violation must also be specified. Reference [20] defines three classes of response behaviour on violation of synchronisation constraints: (i) balking, which is to return immediately with a failure indication; (ii) blocking, which is to wait indefinitely until the constraint is met; (iii) timed waiting, which to wait for up to a maximum time for the constraint to be met, returning with an error otherwise. Whereas the Ada language definition [23] supports all three classes of response behaviour, the Ravenscar Profile excludes the use of timed-wait constructs and limits the use of blocking to at most one waiter per protected entry queue. OBOSS contemplates exclusion constraints and state constraints while it currently has no requirements for the support of coordination constraints. The use of protected objects for the implementation of event buffers allows OBOSS to enforce exclusion constraints in the simplest and most radical form of total mutual exclusion. State constraints hold for OBOSS synchronisation in the classical events of full buffer or empty buffer. The use of HRT-HOOD led OBOSS to model message receivers as sporadic objects. As the design method prescribes, the exported operation Extract of the base class Queue shown in figure 7 maps to a protected entry with blocking response on the state constraint violation of empty buffer. For the state constraint violation of full buffer on sending, instead, OBOSS has opted for a balking response for compliance with the Ravenscar Profile. Accordingly, the Deposit method of Queue maps to a protected procedure that returns a boolean response parameter. A negative response on sending denotes a state constraint violation of full buffer and typically results in the issue of an exception message directed toward a supervisory authority. This behaviour is in accord with what is generally expected of current on-board systems. Earlier in this section we have encountered two code fragments that give rise to balking response behaviour: (i) in the implementation of operation Send Packet of object AP i Packet Dispatcher (cf. figure 10); (ii) in the implementation of operation Receive Packet of object Command Interpreter within class object Service J (cf. figure 12). Table I summarises the data-oriented synchronisation characteristics of OBOSS objects. We maintain that the synchronisation behaviour of OBOSS objects fully meets the applicable requirements of the target application domain. As we mentioned earlier, the present generation of OBOSS classes can be instantiated but cannot be extended. This limitation bounds the reusability potential of OBOSS and weakens the object orientation characteristics of its design. The Queue class presents an obvious case where specialisation would be more powerful and advantageous than instantiation. Its current design suffers from two intrinsic limitations (cf. [6]): the implementation of the object is fixed for any given definition of the internal data structure and of the exported operations Deposit and Extract: a re-definition of the whole module (and thus another OBOSS build altogether) would therefore be required to support any other implementation; Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 22 TULLIO VARDANEGA, GERT CASPERSEN Table I. Data-oriented synchronisation characteristics of OBOSS. synchronisation constraints exclusion state coordination enforcement side server server — enforcement style at sender at receiver total mutual exclusion balking — total mutual exclusion blocking — any given instantiation of the object fully determines the data type that the data structure holds and that the exported operations are able to manipulate (i.e., Element Type): no operation may be thus defined that manipulates the data structure without regard to the actual data stored in it. Potential OBOSS users may well wish to specify the insertion and extraction policy for use by selected software sporadic objects with the respective event buffers. The current implementation fixes the choice to a single solution (e.g.: FIFO, priority based) for all objects within any OBOSS build. This is no intolerable drawback at present, but it may become more of an annoyance in the face of increasing user demand. The issue whether OBOSS includes other components as obviously and as conveniently amenable to extension as the event buffer is the subject of current investigation. The sole downside to unabridged adoption of inheritance by extension lies in the increase in resource requirements that could incur from it, particularly with respect to memory size and predictability of execution. An obvious opportunity for OBOSS to benefit from the expressive power of Ada 95 object orientation stems from the use of tagged types in the place of discriminated records for the handling of polymorphic data objects. The case for tagged types is particularly attractive from the abstraction point of view. It remains to be seen however whether compilers would treat objects of tagged type in a less heap-intensive way than they tend to do for discriminated records in the use context of OBOSS. Compilers use the heap when they cannot statically determine the size of the return parameters of subprograms. The use of the heap however constitutes a potential hazard to the stability of non-terminating programs. Tagged types whose interpretation depends on the context of execution (which Ada calls run-time dispatching) may incur the use of the heap. Any increase in the heap-intensiveness of the treatment of tagged types would obviously undermine their usefulness to OBOSS. As a general principle and in spite of the intellectual interest of unabridged object orientation, OBOSS revisions will always give precedence to the preservation of the current integrity, predictability and resource demand of the system. ☛ Tagged types are the closest Ada 95 gets to the primitive notion of ‘class’ of other object-oriented languages. The inheritance hierarchy rooted at Ada 95 tagged types matches the derivation class of those languages. This view is orthogonal to the notion of OBOSS class used in this paper, which is rooted at the generic package, the ultimate building block of Ada programs. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 23 EVALUATION The challenge for a software reuse framework in the application domain of OBOSS is to respond to seemingly contrasting needs. The chief reuse objective was one of generality, to maximise the unmodified reuse potential while allowing users to adopt the service profile that fits their needs. The major acceptance criterion for onboard software systems in the class of OBOSS, however, focuses on predictability of execution and containment of memory requirements. To achieve the reuse objective, OBOSS has to cover a large cross-section of the PUS service catalog and of the variety of its configuration parameters. To qualify for acceptance, the OBOSS computational model must warrant predictability in the face of scalability and the OBOSS implementation technology must make moderate demands for memory. In the following we analyse how our implementation responded to these needs. We first look at how compliance with the Ravenscar Profile impacts the scalability and the predictability of the system. We then analyse the tribute the OBOSS generality pays to the memory budget of the system. Finally, having determined the acceptability of the technical criteria, we devise a projection technique to predict the ratio of unmodified reuse attainable by OBOSS users. The Ravenscar Profi le as a Limiting Factor The decision to conform the OBOSS concurrency model to the prescriptions of the Ravenscar Profile had so vast repercussion on its design and implementation that it obviously needs assessment. Earlier in this paper we have briefly recalled the restrictions emanate from the definition of the profile. Overall, the prescriptions of the Ravenscar Profile did not present OBOSS with significant implementation problems. In fact, the coding restrictions that emanate from the profile are not distant from the standard coding guidelines traditionally followed by a large fraction of the on-board software community. Ironically, they are even more permissive with regard to the use of native Ada tasking (which was often substituted by custom forms of concurrency). Fitting the Ravenscar Profile in the original OBOSS baseline proved fairly smooth and, in retrospect, particularly natural and convenient to the overall economy of the OBOSS concept. This notion shows that the profile suits well the needs of on-board real-time embedded systems of the new generation. Moreover, our earlier discussion of the OBOSS implementation also shows that the profile provides the object world of OBOSS with an elegant concurrency model. Task Density The combined effect from the OBOSS reuse philosophy and the Ravenscar tasking model calls for a radical ‘specialisation’ of tasks, for tasks can only exhibit a very specific execution behaviour and thus can only adequately perform specific operations. This notion adds to the clarity of design but it also increases the tasking population of the system to unprecedented levels, which demands an unusually large range of priorities. One inescapable consequence of this phenomenon is that Ravenscar-compliant compilers may have to support much larger priority ranges than old Ada technology (i.e., Ada 83) usually contemplated. This phenomenon was fully apparent in our implementation. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 24 TULLIO VARDANEGA, GERT CASPERSEN Table II. Notations. ✂✁ ✄✆☎ ✝ ☎ ✞✠✟ ✝ ✞ total tasking population system infrastructure component application process infrastructure component service framework descriptor application process service descriptor A large task population poses system designers a serious threat in two, arguably orthogonal, dimensions: predictability of execution and scalability of architecture. OBOSS solves both problems efficiently and elegantly thanks to the combined effect of two key features of its design. It earns scalability from the HRT-HOOD computational model, the active terminal objects of which are threaded in accord with the Ravenscar Profile and consequently are freely composeable. It earns predictability from the power of the theories of schedulability associated with the Ravenscar Profile (cf. e.g.: [3]) and from the regularity of its tasking architecture that feeds them the necessary information. OBOSS users can determine exact bounds to the tasking population of the system for any variation of its configuration parameters. In fact, those bounds can be expressed in a fairly elegant fashion, as we illustrate in the following. Table II lists the structural components of OBOSS that feature internal concurrency. Equation 1 shows how those components contribute to the determination of the tasking population in an OBOSS-based system comprised of ✡ local application processes and ☛ agents for remote application processes. ☞✍✌ in the equation is an ✎ ✡✑✏ ✓✒ identity matrix, which we use to reduce the result to vectorial form. ✔✖✕✘✗ ✡✚✙✛☛✢✜✠✣✥✤✦☞★✧✪✩✫☞★✧✭✬✯✮✰✏✱✩✲✬✳✏✴☞ ✌ (1) ✁ ✗✶✵✸✷ ✵✺✹ ✵✺✻ ✙ ✙ ✙✽✼✾✜ tuple, which Each structural component of the equation is expressed in term of a respectively denotes the number of interrupt sporadic threads, software sporadic threads, cyclic threads and protected objects to account for the component. With equation 1 we can easily determine the lower bound and the upper bound to the tasking population for all variants of OBOSS systems. The lower bound is obtained on a system comprised of one agent associated to the TC and TM end of the system (whereby ☛✿✣ ) and one single application process embedding no PUS services (whereby ✡❀✣ ). One such application process —and the resulting system —alone would serve no useful purpose other than acting as a TC destination and a TM producer. For instance, this would be good enough for carrying out electrical integration of the system. The upper bound is obtained when every application process in the system embeds the whole set of ✕ PUS services supported by OBOSS, each✔✖holding one protected state vector. ✖ ✔ ✕ ✗ ✗ ✗▼▲ Eqn. 1 sets the lower-bound value to: min ✣❁✎ ❂✙❄❃❅✙ ✙ ❇❆❈✒ ; whereas for the upper-bound value we ✡✴✜✓✙✽❑✍✡✚✙ ✧◆❑❖☛✂✧ ✸P✸✡✱✜◗✒ . obtain: max ✡✘✙❄☛❉✜✠✣❊✎ ☛❋✙ ●✧❍❆■☛❏✧ ✁ ✁ ✁ ✁ ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls ✁ ✁ Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 25 These bounds confirm the predominantly event-driven nature of control flow in OBOSS and, ✔✖✕ ✔✖✕ all ✗ the tasks in term arguably, in all on-board systems faced with PUS requirements. We note that periodic tasks contribute to term min classify as sporadic, while only ❑✍✡ max ✡✚✙✛☛✢✜ . We reckon that an average OBOSS system would comprise in the lower region of ❑ tasks and well over ❑ protected objects, thus needing some or more distinct priorities. The use of distinct priorities is not a necessary requirement to the construction of a predictable real-time system. Arguably, however, it adds to the simplicity of the runtime implementation (e.g.: by way of avoidance of any form of roundrobin scheduling for equal-priority tasks) and, consequently, to that of the scheduling analysis. The Ada Reference Manual [23] is not prescriptive on the issue of the supported priority range ▲ language implementor. Current Ada technology for 32-bit embedded and leaves the decision to the systems typically support ❆❂❃ priorities (which would be more than adequate for OBOSS) except when it interfaces to foreign operating system technology, where it is the latter to determine the priority range, which it often limits to ❂❆ . OBOSS embeds concurrency directly within its reuse model. This reflects the HRT-HOOD connotation of it, which adds tasking characteristics to the functional properties of its objects. This approach raises the computational power of the reuse components and permits users to determine the tasking population of an OBOSS instantiation for any variation of its configuration parameters. ✁ ✁ ✁ ✁ Sizing Requirements An important dimension of our evaluation has to be the impact of the OBOSS reuse model on the sizing budget of the system. On-board memory is a cost driver for satellite systems in at least two distinct respects: the material cost of its radiation-hardened technology and the demand it places on the power budget of the system. On-board software applications consequently face stringent limitations on the amount of memory required to host and run the system. Any new software technology for use with on-board software applications will always be challenged for its impact on memory and so will OBOSS. Two aspects are especially relevant to our evaluation of this particular issue: (a) the size inflation caused by the inception of the PUS view of DHC systems, the generality and flexibility of which are intrinsically more demanding than traditional tailored-to-needs systems; (b) the size inflation caused by the OBOSS reuse approach with respect to functionally equivalent systems with less emphasis on reuse. Consideration of aspect (a) tells us what cost we have to expect, in the particular respect of on-board memory, upon the transition to the PUS. This cost shall show inferior to the promise of development and operational benefits for the new approach to be of industrial interest. To estimate this cost we relate the code size of a traditional (pre-PUS) DHC system with minimum functionality with the code size of an OBOSS system with the corresponding PUS functionality. In PUS terms, this corresponds to a single application process supporting a classic set of optional services. In establishing the comparison we need to discount the differences in baseline technology used by the respective systems. The traditional system targeted a 16-bit processor with a CISC-like instruction set. The corresponding OBOSS system targets a 32-bit RISC processor. We discount this difference by using a normalisation factor of 3 to denote that a program written for the former architecture will become (about) 3 times bigger when compiled for the latter. We infer this factor on consideration of the doubling of the word size and the more verbose programming style incurred on the transition to 32-bit pipelined architectures. ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 26 TULLIO VARDANEGA, GERT CASPERSEN Table III. Impact of PUS Model and OBOSS Reuse Approach on Code Size (in bytes) pre-PUS 16-bit Ada OBOSS PUS 32-bit Ada other PUS 32-bit C runtime support platform services system infrastructure application process 4,308 21,470 6,492 18,788 14,580 25,506 90,780 79,876 11,420 11,380 12,624 14,760 total PUS inflation factor (normalised) OBOSS reuse inflation factor 51,058 1.00 — 210,742 1.38 4.20 50,184 0.33 1.00 component Consideration of aspect (b) gives an indication of the size overhead that results from the OBOSS emphasis on reuse and its selection of enabling technology. This size overhead shall have to be modest for OBOSS to attract users and deflect them from opting for a custom implementation of the system. To address this dimension we compared the same OBOSS system considered for aspect (a) with a nonOBOSS PUS system developed with non-Ada technology for the same target family but with a much lower reuse objective. Table III shows the details of our evaluation, which we broke down in accordance with the main architectural components identified in figure 2. We attach sufficient trust to the breakdown figures displayed for non-OBOSS systems because we could easily relate their functional constituents to the OBOSS nomenclature. We find a breakdown at this level is useful to identify the system components that exhibit the most variability in memory requirements. As we said earlier, we apply the normalisation factor to the pre-PUS values shown in the table. The Ada-to-Ada comparison shows an inflation factor of ✁ , which we may ascribe to the PUS overhead. In particular, the break-down figures in table III show how apparent the PUS overhead becomes for the system infrastructure component that is most implicated with the interpretation of the PUS communication protocols. The Ada-to-C comparison shows an inflation factor of ✂ , which reflects the considerable overhead of the OBOSS reuse model and the greater language complexity of Ada. This overhead originates in the application-specific components of the system. The Ravenscar runtime used for OBOSS almost equals in size the stripped runtime used for pre-PUS Ada system and pays a little overhead tribute to the real-time kernel used for the C system. OBOSS moves specialisation to the low-level tier of the system (the platform services component) which can be tailored to needs and therefore restrain its size overhead. Conversely, OBOSS moves reuse-geared flexibility to the higher-level tiers of the system, which consequently pay a significant overhead tribute to custom implementations. The PUS-related inflation factor denounces a wholly acceptable overhead, which the many comparative advantages of the PUS service model richly pay for. ✁ ❑ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls ❑ ❆ Softw. Pract. Exper. 0000; 0:0–0 27 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS The OBOSS-related inflation factor challenges the OBOSS reuse model. The overhead factor for which the OBOSS implementation is directly responsible can only be responded by a major increase of reuse value with respect to less reuse-geared competitor technology. We will see in the following section that OBOSS features a potential for unmodified reuse that arguably pays off its tribute to size overhead. Reuse Ratio The promise of unmodified reuse needs quantification. Project managers need quantitative information to assess the pros and cons of design baselines, especially when they involve the adoption of software reuse frameworks with the characteristics of OBOSS. Next to the design and implementation of OBOSS we have developed a method for the determination of the unmodified reuse ratio that users can attain. In the following we illustrate the rationale and the product of the method. From a reuse perspective, an OBOSS-based system comprises two basic categories of constituents: (i) components that form part of the OBOSS reuse infrastructure and the user simply needs to configure for the system in question, typically by way of generic instantiation; (ii) components that are platformspecific or system-specific, and that the user needs to provide, typically in the form of actual generic parameters or as bodies of prescribed specifications or else as self-standing components with no direct interface to OBOSS reuse assets. For the purpose of this discussion we may regard an OBOSS-based system as a cascading hierarchy of such components. At the top of the hierarchy we find the OBOSS notion of PUS system, which encompasses: (a) the OBOSS reuse infrastructure at system level, which allows the system to hang together; (b) user-supplied services that enable the system to perform platform-specific operations, like writing to and reading from physical devices; (c) a battery of application processes ( ) which embed the set of PUS service capabilities specifically required of the system. ) includes: One level down in the hierarchy, the OBOSS notion of application process ( ✂✁ ✄✁ (d) the OBOSS reuse✷ infrastructure at this level, which allows the application process to hang together and includes a set ☎ of service capabilities implemented as generic instantiations; (e) a collection of user-supplied modules that define the system-specific attributes of the application ✷ process, including any functional capabilities not prescribed by the PUS standard. At the bottom level of the hierarchy, a generic service instantiation ✝✆ (✟✞✠☎ ) of application process comprises: (f) the OBOSS reuse infrastructure at service level; ✷ the generic actual parameters required for the ✷ service. ✷ (g) the user-supplied definition of of application process is of cardinality ✡ (✡ min ✁ ✡ The service capability set ☎ ✁❁✡ max ) where ✡ min denotes the minimum number of services required by the standard per application process ✷ the standard. Individual services are uniquely and ✡ max denotes the total number of services allowed by ✷ an ordered ✷ set of indices▲ in that identified by an index in the range ✎ ✍✙✛✡ max ✒ so that ☎ is effectively ☞ ✡ ✡ ✣ ✌ ❆ ✁✭✡ ✁❍✡ max ✁ ❆✍❃ ✎✙ ✍ . range. The current version of the PUS standard prescribes that ☛ Our method determines the value of ✏ (with ✁✑✏✒✁ ), that is, the level of unmodifi ed reuse potentially attained in the development of an OBOSS system build, relative to the total size of the system. ✁ ✆ ✆ ✁ ✆ ✝ ✆ ✆ ✁ ✆ ✁ ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 28 TULLIO VARDANEGA, GERT CASPERSEN Table IV. Components of an OBOSS-based system. level system application process ✞ service ✞✒✑ (✓✕✔✗✖✙✘ ) component origin size infrastructure platform services infrastructure add-on infrastructure add-on OBOSS new OBOSS new OBOSS new ✂✁☎✄ ✁☎✝ ✠✟ ✄☛✡ ✠✟ ✝✏✡ ✛✚ ✄☛✡✢✜ ✛✚ ✝✏✡✤✜ instances ✆ ✆✌☞ ✞ ✎ ☞ ✍ ✣ min ☞ ✣ ✘ ☞ ✣ max The structure of an OBOSS-based system is inherently such that increases with the density of OBOSS-supported PUS services per application process and with the number of such application processes in the system. Table IV itemises the components of an OBOSS-based system indicating the hierarchical level at which they place, the respective supplier, the symbol denoting their size and their recurrence at that level. All of the OBOSS-specific symbols in table IV that denote size have statically known values, which represent permanent attributes of the relevant reuse assets. For example, the system infrastructure component ( ✥✛✦★✧ ) presently amounts to about 5,000 source statements. For the non-OBOSS components, one would do with size projections for new components, or with actual data for existing ones. In general, the non-OBOSS component providing the so-called platform services (cf. figure 2) represents the largest unitary component of the system, with a size (✥ ✦✪✩ ) that may approach the lower region of 10,000 source statements for systems of the new generation. ✫ Using the actual values associated to the size symbols of table IV, which we omit for the sake of simplicity, we determine the overall estimated size of an OBOSS-based system (which we denote ✥ ) and, from that, the amount of unmodified OBOSS reuse achieved within it (which we denote ). For every OBOSS reuse component, the size of the unit contributes to the running total of unmodified reuse. Similarly, for every user-supplied component, the size of the unit contributes to the running total of the required development. The ‘instances’ indicator of table IV determines how many times the contribution of individual components needs to be accounted for at that hierarchical level. We have studied the behaviour of under the hypothesis of a mean density of PUS services per application process within a system populated with multiple application processes. We have chosen a value for in the range and we have assumed the usual OBOSS coverage of moderate those services, in the region of 80% per application process. (That is, for an application supporting services, of them usually happen to match the OBOSS offer.) ✏ ✏ ❑ ✬ ✡ ✷ ✏ ✎ ❂✙ ✚✣ ✆ ✁ ✁ ✁ ✒ ❃ ✭ ✁☎✝ Note that for traditional systems hardly exceeds 5,000 source statements on account of the considerably less stringent demand for autonomous capabilities of on-board fault tolerance. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 29 Mean Density 75 70 Extent of Unmodified Reuse 65 60 55 50 45 40 15 Figure 14. 20 25 30 35 Total Size in Source Statements ✁ ✆☎ ✞✝ 40 as a function of for mean density of services ( application process ( ). ✆ ✞ ✆ 45 50 ✂✁ ✄ ) per ✣ ✘ Figure 14 plots the resulting over an x-axis that denotes , which increases with the number of application processes in the system. ✄ for system sizes in The plot in figure 14 exhibits a logarithmic behaviour with approaching P ✁ ✁ ✁✂✁✂✁ ✁ source statements (equivalent to a very large system with over ✠✟ application excess of ✙ ✁ ✂ ✁ ✁ processes). ▲ For more typical values of in the region of ❆❂❃✢✙ source statements and ☛✡✌☞✎■✍ ❃ , ✁ ✄ approaches . We contend that this level of unmodified reuse is a target worthy of industrial interest and a sufficient bonus for the size overhead paid to less reuse-geared approaches. The benefit of the OBOSS reuse model especially shows as we note that OBOSS promises this level of unmodified reuse to a wide range of system configurations, which is well outside the reach of custom implementations. ✏ ✥ ✏ ✁ ✁ ✥ ✏ CONCLUSION In this paper we have presented an engineering approach to software reuse that attained a considerable potential for unmodified reuse in conjunction with a high degree of architectural scalability. Our engineering approach looked at software reuse from the three complementary and inter-related perspectives of ‘reuse by architecture’, ’reuse by artifacts’ and ‘reuse by technology’. The emergence of a domain-specific standard especially tailored to our application domain greatly facilitated our endeavour, particularly with regard to the architecture and artifacts dimensions. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 30 TULLIO VARDANEGA, GERT CASPERSEN The embedding of Ravenscar concurrency within Ada generics was the technology solution that earned our software architecture an excellent blend of scalability and predictability. The combined use of both language features proved a powerful and expressive means of implementation. As a reflection of a code legacy largely rooted in the object based connotation of Ada 83, our software is not a champion of pure object orientation. This limitation did not preclude us the ability to factorise a large proportion of our code efficiently. Yet, analysis is on-going at the time this paper is being written to determine what aspects of language-level object orientation could be advantageous to our concept. In order to ease the transposition of the engineering approach presented in this paper to application domains other than ours we deliberately restrained the discussion of domain-specific aspects. Disclaimer: The views expressed in this paper are those of the authors’ only and do not necessarily engage those of the European Space Agency. REFERENCES 1. Aonix. ObjectAda Real-Time RAVEN http://www.aonix.com/content/products/objectada/raven.html 2. Audsley, N, Burns A, Richardson M, Wellings A. Hard real-time scheduling: the deadline monotonic approach. In Proc. Real-Time Operating Systems and Software 1991; 8:127–132, Atlanta, GA (USA), IEEE. 3. Audsley, N, Burns A, Wellings A. Deadline monotonic scheduling theory and application. Control Engineering Practice 1993; 1(1):71–78. 4. Boehm, B. Managing software productivity and reuse. IEEE Computer 1999; 32(9):111–113. 5. Burns A. The Ravenscar profi le. Ada Letters 1999; XIX(4):49–52. 6. Burns A, Wellings A. Concurrency in Ada (2nd edn). Cambridge University Press, 1988. 7. Burns A, Wellings A. HRT-HOOD: A structured design method for hard real-time systems. Real-Time Systems 1994; 6:73–114. 8. Burns A, Wellings A. HRT-HOOD: A Structured Design Method for Hard Real-Time Systems Elsevier Science, 1995. ISBN 0-444-82164-3. 9. Consultative Committee for Space Data Systems 1987. Telecommand Summary of Concept and Service CCSDS 200.0-G-6 Issue 6. http://www.ccsds.org 10. Consultative Committee for Space Data Systems 1987. Telemetry Summary of Concept and Rationale CCSDS 100.0-G-1 Issue 1. http://www.ccsds.org 11. CRI 1997. Guidelines for the development of reusable onboard software. Technical Report CRI/OOSS/WP-1.2.1/001 on ESTEC Study Contract No. 11277/94/NL/FM(SC), European Space Agency, Noordwijk, NL. http://ftp.estec.esa.nl/pub/ws/wsd/oboss/www/oboss.html 12. de la Puente J, Ruiz J, Zamorano J. An open Ravenscar real-time kernel for GNAT. In H. Keller and E. Ploedereder, editors, Proceedings of the 5th International Conference on Reliable Software Te chnologies — Ada-Europe 2000; Lecture Notes in Computer Science, Springer-Verlag, 1845:5–15. 13. Dornier Satellitensysteme 1995. Candidate domain analysis. OBOSS-I Web Repository - Documentation - Appendix A Product of ESTEC Contract 11277/94/NL/FM(SC). ftp://ftp.estec.esa.nl//pub/ws/wsd/oboss/www/oboss.html 14. Dornier Satellitensysteme 1999. Sw system development for SC data handling and control - domain analysis. OBOSS-II Web Repository - Domain Analysis Product of ESTEC Contract 12797/98/NL/PA. http://spd-web.terma.com/Projects/OBOSS/ObossII\_domain\_analysisB.pdf 15. ESTEC 1996-1999. 32-bit Microprocessor and Computer System Development. Study Contract No. 9848/92/NL/FM, European Space Agency, Noordwijk, NL. http://www.estec.esa.nl/wsmwww/erc32/erc32.html http://www.temic-semi.com/nt/ams/sparc/sparc.htm 16. European Space Agency 1988. Packet Telemetry Standard. PSS-04-106 Issue 1. 17. European Space Agency 1992. Packet Telecommand Standard. PSS-04-107 Issue 2. 18. European Space Agency 1994. Packet Utilisation Standard. PSS-07-101 Issue 1. Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0 ENGINEERING SOFTWARE REUSE FOR SPACEBORNE SYSTEMS 31 19. Griffi n W. Lessons learned in software reuse. IEEE Software 1995; 12(4):11. 20. Holmes D, Noble J, Potter J. Effective synchronisation of concurrent objects: laying the inheritance anomaly at rest. Technical report, Department of Computing, Macquarie University, Sydney, AU 1998. http://www.mri.mq.edu.au/$\sim$dholmes/research/oopsla-paper-submission.html 21. HOOD Technical Group. HOOD Reference Manual 3.1. Prentice Hall, 1993. 22. ISO. Ada Reference Manual. International Standardisation Organisation 1987. ISO/IEC 8652:1987. 23. ISO. Ada Reference Manual. International Standardisation Organisation, 1995. ISO/IEC 8652:1995. 24. Maxwell K, van Wassenhove L, Dutta S. Software development productivity of European space, military and industrial applications. IEEE Transactions on Software Engineering 1996; 22(10):706–718. 25. Mili A, Yacoub S, Addy E, Mili E. Toward an engineering discipline of software reuse. IEEE Software 1999; 16(5):22–31. 26. Mili M, Mili F, Mili A. Reusing software: issues and research directions. IEEE Transactions on Software Engineering 1995; 21(6):528–562. 27. Terma 1999. Software system development for spacecraft data handling control. OBOSS-II Home Page Product of ESTEC Contract 12797/98/NL/PA. http://spd-web.terma.com/Projects/OBOSS/Home\_Page 28. Vardanega T, Caspersen G. Using the Ravenscar profi le for space applications: the OBOSS case In M. González Harbour, editor, 10 International Real-Time Ada Workshop, Ada Letters 2001. XXI(1):96–104. 29. Vardanega T, van Katwijk J. Productive engineering of predictable embedded real-time systems: the road to maturity. Information and Software Technology 1998; 40(13):745–764. 30. Vardanega T, van Katwijk J. A software process for the construction of predictable on-board embedded real-time systems. Software - Practice and Experience 1999; 29(3):235–266. 31. Wichmann B. Programming languages - guide for the use of the Ada programming language in high integrity systems. Technical Report ISO/IEC TR 15942, International Standardisation Organisation, 2000. (A pre-fi nal version can be found at: http://www.dkuug.dk/jtc1/sc22/wg9/n359.pdf) ✁ Copyright c 0000 John Wiley & Sons, Ltd. Prepared using speauth.cls Softw. Pract. Exper. 0000; 0:0–0