HRT-HOOD Specification used. in OBOSS-II. TERMA Doc. no.: TERMA/69/OBOSS-II/TN-008 Date: Issue: 1 Revision: 1

Transcription

1 HRT-HOOD Specification used in OBOSS-II TERMA Doc. no.: TERMA/69/OBOSS-II/TN-008 Date: Issue: 1 Revision: 1 Distribution: ESTEC, TERMA Prepared by: Morten Rytter Nielsen Approved by: Jan Storbank Pedersen Authorised by: Gert Caspersen

2 ii

3 The intellectual property right of this document is vested in TERMA Elektronik AS. iii

4 Document Change Record Issue Date Change 1.d Draft issue of document Document Status Sheet Page Issue i vi iv

5 Table of Contents 1 Introduction Scope Documents Applicable Documents Reference Documents The Used Programming Model 3 4 The Used HRT-HOOD Specification Model HRT-HOOD Specification Method Semantics of HRT-HOOD Specification Specification of Operations Related to Elaboration Cyclic Objects Protected Objects Sporadic Objects PIO Objects Generic Instantiations HRT-HOOD Design Decisions HRT-HOOD Class Objects and Ada Generic Packages Provided Interface Combined Objects Protected and Cyclic objects Types of the Operations Data Flows Exception Flows Mapping to Ada General Generic Objects PIO Objects Sporadic Objects Ada Code Cyclic Objects Ada Code Protected Objects v

6 6 Conformance with HRT-Hood Design level: Design nonconformance with HRT-HOOD method as reported by the toolset Code level: Use of generic packages Sporadic Objects Cyclic Objects Protected Objects ESF and UCF ESF UCF vi

7 1 Introduction 1.1 Scope This document together with the HRT-HOOD design forms the specification of an instance of the OBOSS-II SW inspired by the functionality of the PROBA On-Board SW. The purpose of the HRT-HOOD design is to be able to make a schedulability analysis of an instantiation of the OBOSS-SW. This purpose is reflected in the choices made in this document about the design and should be kept in mind when reading it. In this document we do not use a strict terminology and might somewhere use Ada terms in describing the HRT-HOOD design. Stating e.g. that an HRT-HOOD object is instantiated means that the Ada package implementing the object is a generic package and this package is instantiated. 1

8 2 Documents 2.1 Applicable Documents 2.2 Reference Documents [Ada-83] Reference Manual for the Ada Programming Language, United States Department of Defense, ANSI/MIL-STD-1815A-1983, 1983 [Prog-model] Tool Support for the Construction of Statically Analysable Hard Real-Time Ada Systems, Tullio Vardanega, ESTEC, 1996 [PUS] Packet Utilisation Standard, ESA, PSS , Issue 1, 1994 [HRT-HOOD] HRT-HOOD: A Structured Design Method for Hard Real-Time Ada Systems, Volume 3, Alan Burns and Andy Wellings, Elsevier, 1995 [ERC32-temp] HRT-HoodNICE Code Extractor Templates for ERC32-based Aonix/Alsys Ada Targets, Delivery Note, Alessandro Paganone, Intecs Sistemi S.P.A., July 21, 1997 [Hybrid-task] Analysis of Hybrid Task Specification and Reimplementation, Morten Rytter Nielsen, Terma Elektronik, 1998 [ADD] Software System Handling Development for Spacecraft Data Handling & Control - Data Handling System Architectural Design Document, Morten Rytter Nielsen, Terma Elektronik,

9 3 The Used Programming Model The used programming model closely corresponds to the one suggested in [Prog-model]. 3

10 4 The Used HRT-HOOD Specification Model 4.1 HRT-HOOD Specification Method We refer to [HRT-HOOD] for information on the HRT-HOOD Specification Method. 4.2 Semantics of HRT-HOOD Specification Specification of Operations Related to Elaboration In the implementation of objects the two operations Initialize and Go may be present in each package implementing an object. Initialize does a post-elaboration of a package and Go starts the tasks in the package 1 and thus only after the Go operation has been called can Rendezvous take place with the tasks in a package. We have decided not to include the operations Initialize and Go in the HRT-HOOD design, because this would clutter the design and not serve any real purpose. If an object has a number of child objects, an extra object might have to be specified (with an Initialize and a Go operation which implements the parent object s operations Initialize and Go). This object s sole purpose would be to call the Initialize and Go operations in the other child objects. The object would be needed because only terminal objects can call operations in other objects in HRT-HOOD. Nevertheless we will sometimes in the implementation have an Ada package with the sole purpose to initialize and start other applications and services. It this case we will specify an object corresponding to this package. Thus we will have specified an object for each Ada package Cyclic Objects In the HRT-HOOD methodology the execution of a cyclic object is started either immediately it is created or after some defined time offset. This is based on the assumption that the system 1 Note that the Go operation is not equal to the event that starts the sporadic execution in a sporadic object but can be considered as being part of the elaboration 4

11 has some initial setup time (e.g. elaboration time) after which every object is created and ready to execute. The OBOSS SW uses another approach where after the system has been initialized objects with its own tread of control are started by requesting the execution of the operation Go in them. HRT-HOOD does not allow other operations than ATC type operations (i.e. ATC type operations are operations of one of the types ASATC 2, LSATC 3, TOER LSATC 4, HSATC 5 and TOER HSATC 6 ) to be present in cyclic objects. So either we make the Go operation of one of the ATC types or do not specify this operation in the specification (as is the case for Initialize and Go for sporadic objects). We have chosen not to specify the Go operations as they in some way are part of the initialization of the system and not used in a schedulability analysis Protected Objects If operations in protected objects calls operations in other protected objects that are of the type PSER then these operations will themselves be of type PSER Sporadic Objects The HRT-HOOD tool that we use does not allow operations in sporadic objects with other names that Start to be of type ASER 7. The design does not have any unconstrained operations in sporadic objects, therefore we have decided that ASER type of operations in sporadic objects will be displayed in the design as unconstrained PIO Objects If there are operations in the provided interface of a parent sporadic object which are not Initialize, Go or operations which are implemented by child objects operations then these operations will be located in an object prefixed with PIO 8. This is done to explicitly stress relationships between these operations and the other child and environment objects in the parent object. Another reason for doing this is that in HRT-HOOD all operations have to be either implemented-by another operation or located in a terminal object. A PIO object has exactly the same environment as its parent. Therefore we do not explicitly specify the environments of PIO objects in the specification. 2 Asynchronous, asynchronous transfer of control request 3 Loosely synchronised asynchronous transfer of control request 4 Timed-out loosely synchronised asynchronous transfer of control request 5 Highly synchronised asynchronous transfer of control request 6 Timed-out highly synchronised asynchronous transfer of control request 7 Asynchronous Execution Request 8 Provided Interface Object 5

12 The type of a PIO object is normally the same as the type as its parent 9. But for the objects where this is not the case we will specify the types of the PIO object s operations Generic Instantiations In the HRT-HOOD design we stress the relationship between an object and the objects that it depends on. Such a dependency can either come from a direct dependency corresponding to an Ada with clause or from an indirect dependency coming from generic actual parameters. The HRT-HOOD methodology does not distinguish between these different types of dependencies. But we would like to encapsulate this information in our design when operations are passed as actual generic parameters. For this purpose we specify a protected object with the name of the object that is instantiates (in the Ada implementation) but postfixed with Gen Act Param. This protected object has a provided interface corresponding to the operations used in the instantiations of the former object except that the type of the operations are unconstrained. Notice that because we have decided only to specify these objects when operations are present it might look as if an object in the design is self-contained even if it is dependent on generic actual parameters of the parent object. 4.3 HRT-HOOD Design Decisions HRT-HOOD Class Objects and Ada Generic Packages We do not have any class objects 10 in the design. We have though specified objects corresponding to instantiations of generic packages in Ada. The reason that we have not used class objects is that in the HRT-HOOD tool that we use, an instance of a class object can only have use relations to the project s 11 environment objects and not to objects specified inside the project. This is also partly why we have chosen to specify an instance of the OBOSS SW and not the generic SW itself (another reason is that the schedulability analysis demands knowledge on periods, number of instances of services etc which is only available for the instantiated SW). We prefix the object names of objects that correspond to instantiations of generic packages in Ada with The. An object might because it is an instance depend on objects that do not exist in the corresponding Ada package in the OBOSS SW. The instantiation might even depend on a generic parameter from the parent or grandparent. Because of the way we have chosen to specify generic depen- 9 Exceptions are e.g. cyclic objects with child objects that are protected. These are discussed in section HRT-HOOD class objects would correspond to generic packages in the Ada code 11 The HRT-HOOD tool from Intecs uses the term project to denote the outermost structuring mechanism which incorporates the top-level objects in a design 6

13 ASER Start S The_X Gen_Act_Param_Example Pr The_X_Gen_Act_Param E Env_Obj_1 Operation_1 Pr Y Operation_1 Figure 1 The parent dencies using Gen Act Param objects as described in section it is possible to deduce from where an actual generic operation come from as we will see in the following example. Example In figure 1 the object The X corresponds to an Ada package which is an instantiation of a generic package. The generic actual operation is Operation 1 which comes from the object Y. Because of the use relation between The X and The X Gen Act Param the latter object is visible to the childs of The X as can be seen in figure 2. Thus if the Ada package corresponding to The X Child is instantiated with the operation Operation 1 then The X Child Act Param Obj has a use relation to The X Gen Act Param and has an operation named Operation 1. This way of specifying the system allows the user to track the generic actual operations through the design (e.g. Operation 1) and see where the dependencies for the different instantiated objects come from (e.g. the object The X directly depends on the environment object Env Obj 1 and because of its generic instantiations it indirectly depends on the object Y). 7

14 S The_X S The_X_Child ASER Start E Env_Obj_1 Pr The_X_Gen_Act_Param ASER Start Pr The_X_Child_Gen_Act_Param Operation_1 Figure 2 The child 8

15 4.3.2 Provided Interface We have restricted the provided interface to only contain the provided operations and not the provided exceptions or constants. This follows the line of the specification used in generic instantiations. 4.4 Combined Objects In this section it will be discussed what type an object that includes objects of different types will have Protected and Cyclic objects In some objects (e.g. The ACS Monitor.The Event Reporter) we have both protected objects and cyclic objects. The protected objects might e.g. contain some data that the cyclic objects request with a given period. These data might be changed by objects located outside the combined object and thus the combined object s provided interface must have appropriate operations for this. The nature of the combined object is cyclic and thus the type of the object should be cyclic (or active). The operations provided by the interface of this combined object should ideally be protected operations but HRT-HOOD does not allow protected operations on cyclic objects. Alternatively we could make the combined object an active object. The disadvantage is that only active objects can include active objects, thus making the combined object active would propagate up through the design and make every object that includes it active. The combined object could be split up into two objects, one with the protected objects and one with the cyclic objects. This would though not follow the implementation of the system which is best described with only one object (i.e. corresponding to a single Ada package). We have chosen to make the combined object active. This allows the operations that are exported by the combined object and which are implemented by a START operation (ASER) in a sporadic object to also be of type ASER. Operations in the combined objects that are mapped to PSER operations 12 in child protected objects are given the type HSER 13. Note that this decomposition is legal in HRT-HOOD. 12 Protected Synchronous Execution Requests 13 Highly Synchronous Execution Request 9

16 4.5 Types of the Operations HRT-HOOD has a general decomposition scheme where every parent operation is implementedby a single child operation. This is contrary to HOOD where a parent operation can be implemented by several child operations by the use of an op control object. In HRT-HOOD an object can be introduced to allow a single operation to be decomposed into several operations (e.g. the operation in question is implemented-by a operation with the same name which is located in an object with this operation as the only provided interface. The use relationships for this object defines the dependencies for this operation). We will not specify such single objects just to stress the relations between single operations and their decomposition but will keep the decomposition on an object (i.e. Ada package) level in order to keep the overview of the design. Operation types will nevertheless propagate up through the operation levels based on the worst case operation type (i.e. the most restrictive type). E.g. if an operation uses a constrained operation of type PSER then the operation will itself be restrained to be of type PSER (or more restrictive). For the first increment of the design we will not specify functional activation constraints. But if we later decide to include these we will do it in the following way: If there is a functional activation constraint on an operation every operation that uses this operation may also have the same functional activation constraint. Rather than letting these functional activation constraints propagate up to the operations calling them, we define a functional activation constraint for each of the calling operations as references to the operations giving rise to the constraint (E.g. a reference in the ODS could be ref The Monitor Parser.Unparse Monitoring List Report). 4.6 Data Flows For the design we will not specify any data flow because it is not essential for the schedulability analysis. 4.7 Exception Flows For the design we will not specify any exception flow because it is not essential for the schedulability analysis. This corresponds to the decision on the details included in the provided interface made in section

17 5 Mapping to Ada 5.1 General We map the HRT-HOOD design to Ada and compile it using the Alsys ERC32 Ada Cross- Compiler (possibly using Alsys specific constructs and library routines). 5.2 Generic Objects As mentioned in section then objects in the HRT-HOOD design which corresponds to instantiated generic Ada packages are prefixed with The. This is however not reflected in the Ada implementation where Ada packages which are instantiated generic Ada packages might or might not be prefixed with The. 5.3 PIO Objects A single Ada package implements each object and its PIO object (if one such is specified). 5.4 Sporadic Objects In [HRT-HOOD] pg. 26 and pg. 27 the HRT-HOOD semantic for dealing with an ASER operation (Start) in sporadic objects is described. When an ASER is received while the sporadic object is in its enforced delay the ASER is not handled until the delay expires. Thus this indicates that the Ada implementation should handle an ASER request and then delay the rest of the minimum inter arrival interval before handling the next request. This implementation will not allow bursts of events to be handled within one period but will execute the first ASER operation in the given period and the rest in successive periods. This will ensure that the implementation behaves as indicated by the schedulability analysis but will though require some reasoning on how many ASER operations that are to be buffered for each of the sporadic tasks. The ASER operations must either be hard with a sufficiently late deadline, or soft. An alternative implementation of the sporadic task is to allow ASER operations to be executed as soon as the preceding operation in the given object is finished. This will allow bursts of 11

18 operations to be executed within one period of minimum inter arrival interval and thus makes the schedulability analysis a little more complicated. We have chosen the latter way of implementing sporadic objects Ada Code Sporadic objects in the design are implemented as instantiations of the generic package Sporadic Task. The specification part of this generic package is: with Task_Priority_Control; with Mission_Parameters; generic... My_Application_ID : in Mission_Parameters.APID; Sporadic_Event_Buffer_Size : in Positive := 1; -- No violation of minimum inter-arrival time is detected. -- Only Sporadic_Event_Buffer_Size number of calls are buffered. with procedure Sporadic_Operation (Sporadic_Parameter : in Sporadic_Operation_Parameter_Type); package Sporadic_Task is... --% Active Tasks: --> The_Sporadic_Task - Sporadic --% Passive Tasks: --> Event_Buffer.Queue_Task - Critical region ensuring atomic execution on --+ operations on queue of execution requests. procedure Go; --% Subprogram: -- Request execution of Sporadic_Operation using parameter Sporadic_Parameter. -- If Sporadic_Event_Buffer_Size requests are already buffered for execution, --+ request is ignored and result of operation is false. Otherwise request is --+ buffered, and result is true. --% Parameter Constraints: --> None --% Exceptions Raised: --> None function Start (Sporadic_Parameter : Sporadic_Operation_Parameter_Type) return Boolean; end Sporadic_Task; The body part is: with Task_Priority_Control; with Event_Reporting; with Queue; package body Sporadic_Task is... --% Package: -- Queue of execution requests. Has FIFO properties. package Event_Buffer is new Queue (Element_Type => Sporadic_Operation_Parameter_Type, Queue_Size => Sporadic_Event_Buffer_Size, 12

19 Queue_Task_Priority => Event_Buffer_Task_Priority); task type Sporadic_Task is --% Internal Task Type: -- Implementation of sporadic control structure using Ada tasks --% Task Entry: -- Release task implementing sporadic control structure. -- Introduced to eliminate elaboration errors. --% Parameter Constraints: --> None --% Exceptions Raised: --> None entry Go; end Sporadic_Task;... The_Sporadic_Task : Sporadic_Task; procedure Go is begin -- Go The_Sporadic_Task.Go; end Go; function Start (Sporadic_Parameter : return Boolean is Sporadic_Operation_Parameter_Type) begin -- Start return Event_Buffer.Deposit(Sporadic_Parameter); end Start; task body Sporadic_Task is Current_Event : Sporadic_Operation_Parameter_Type; begin -- Sporadic_Task -- Assign task priority dynamically. -- Required as actual generic parameters are not static, meaning --+ that they cannot be used in pragma Priority. Task_Priority_Control.Assign_Priority_To_Current_Task(Sporadic_Task_Priority); accept Go; Wait_For_Event_And_Execute_Operation: loop -- We will block on Event_Buffer.Extract until an execution request is --+ available. Current_Event := Event_Buffer.Extract; Sporadic_Operation(Current_Event); end loop Wait_For_Event_And_Execute_Operation; exception when others => -- Sporadic_Operation should never raise exception. -- If so, we report the event and die! Event_Reporting.Make_Exception_Report(Application => My_Application_ID); end Sporadic_Task; end Sporadic_Task; 13

20 5.5 Cyclic Objects This package uses the Alsys Real Time provided package for waiting until the time where the event (cyclic operation) is to be released (System Clock.Delay Until is a renaming of Real Time.Delay Until) Ada Code Cyclic objects in the design are implemented as instantiations of the generic package Cyclic Task. The specification part of this generic package is: with Task_Priority_Control; with Mission_Parameters; generic --% Generic Parameter Constraints: --> Cyclic_Operation - Must never propagate an exception out of the call. -- My_Application_ID is application ID for associated application process. -- Used for generation of event reports in case of unhandled exceptions --+ propagated out of Cyclic_Operation My_Application_ID : in Mission_Parameters.APID; -- Priority and stack size of cyclic object performing parameter monitoring Cyclic_Task_Priority : in Task_Priority_Control.Active_Task_Priority; Cyclic_Task_Stack_Size : in Natural; -- Period of cyclic task by which Cyclic_Operation is executed. Cyclic_Task_Period : in Duration; -- Operation to be executed by cyclic task. with procedure Cyclic_Operation; package Cyclic_Task is --% Library Package: -- Implementation of control structure corresponding to cyclic task as --+ defined in HRT-HOOD. --% Active Tasks: --> The_Cyclic_Task - Cyclic --% Passive Tasks: --> None procedure Go; end Cyclic_Task; The body part is: with Task_Priority_Control; with Event_Reporting; with System_Clock; package body Cyclic_Task is --% Library Package Body: -- Cyclic task has to be a task object, as stack size can only be --+ prescribed for task types. --% Limitations: -- None 14

21 -- Period of cyclic task expressed according to System_Clock. Period : constant System_Clock.Interval := System_Clock.To_Interval(Cyclic_Task_Period); task type Cyclic_Task is --% Internal Task Type: -- Implementation of cyclic control structure using Ada tasks --% Task Entry: -- Release cyclic execution. -- Introduced to eliminate elaboration errors. --% Parameter Constraints: --> None --% Exceptions Raised: --> None entry Go; end Cyclic_Task; Assign stack size according to generic actual parameter for Cyclic_Task Storage_Size use Cyclic_Task_Stack_Size; The_Cyclic_Task : Cyclic_Task; procedure Go is begin -- Go The_Cyclic_Task.Go; end Go; task body Cyclic_Task is --% Internal Task Body: -- Schedule all consecutive invocations of periodic operation --+ according to System_Clock.System_Start_Time. -- Uses absolute delay-until operations to avoid jitter potentially --+ introduced by relative delay. -- Absolute time for next invocation of operation. Next_Time : System_Clock.Time; -- Access infix operators on System_Clock.Time use System_Clock; begin -- Cyclic_Task -- Assign task priority dynamically. -- Required as actual generic parameters are not static, menaing that --+ they cannot be used in pragma Priority. Task_Priority_Control.Assign_Priority_To_Current_Task (Cyclic_Task_Priority); accept Go; Next_Time := System_Clock.System_Start_Time + Period; Cyclically_Execute_Operation: loop System_Clock.Delay_Until(Next_Time); 15

22 Next_Time := Next_Time + Period; Cyclic_Operation; end loop Cyclically_Execute_Operation; exception when others => -- Cyclic_Operation should never raise exception. -- If so, we report the event and die! Event_Reporting.Make_Exception_Report (Application => My_Application_ID); end Cyclic_Task; end Cyclic_Task; Protected Objects Protected objects can basically have two types of operations: PSER 14 and PAER 15. A PSER operation can also have a functional activation constraint or a timeout (TOER PSER in which case it must also have a functional activation constraint). Our mapping from HRT-HOOD protected objects to Ada does not give a protected object it s own tread of control so PAER type of operations is not possible in the Ada implementation and thus we doesn t use this type of operations in the HRT-HOOD design either. Alsys does not allow time-outs in operations in passive tasks so in the design we haven t specified any operations with time-outs. We map HRT-HOOD protected objects to Alsys Passive Tasks to minimize the overhead associated with calling an HRT-HOOD protected operation in a protected object (semaphores are not available in the Alsys compiler). The compiler does allow calls to passive tasks to take place inside a passive task (e.g. a call from inside a passive task to a function which uses a passive task is allowed). We have nevertheless avoided this construct in the design because it would require two context shifts where really only one is needed. Thus when the HRT-HOOD design has a constrained operation in a protected object that directly or indirectly calls a constrained operation in another protected object we use a special mapping to Ada where the highest level passive task (i.e. biggest critical region) is used to protect also the lower level passive task Protected Synchronous Execution Request 15 Protected Asynchronous Execution Request 16 This approach seems feasible in the applications we have but can of cause normally introduce significant overhead in systems 16

23 6 Conformance with HRT-Hood 6.1 Design level: Design nonconformance with HRT- HOOD method as reported by the toolset There are no problems with the design reported by the HRT-Hood toolset s HRT-Checker algorithm. 6.2 Code level: Use of generic packages As every Ada implementation of sporadic and cyclic object are instantiations of Ada generic packages. It suffices to argue that the code in the generic packages are HRT-Hood complient in order to argue HRT-Hood complience of all the actual sporadic and cyclic objects Sporadic Objects All sporadic objects in the ada implementation of the system are instantiations of the generic package shown in section As only ASER type of operations are used in the system (see section 4.4.1) the generic package only implements this type of operation on sporadic objects. The requirements for this type of operation is that the caller does not block on the request no matter if the called object is not ready to service the given request. This behaviour is ensured by Event Buffer which is a passive task with a FIFO buffer with sporadic invocation parameters. When the sporadic object is ready to service the next invokation/call it fetches the parameters from the Event Buffer and starts the handling of the event. Thus the called is never blocked and the implementation of the operation corresponds to the HRT-Hood ASAR type of operation Cyclic Objects All cyclic objects in the ada implementation of the system are instantiations of the generic package shown in section This implementation ensures that when the cyclic period was passed the corresponding task is envoked and starts execution. Ofcause higher priority level tasks may immediately preemptive this cyclic task and thus delay the cyclic operation until later Protected Objects HRT-Hood Protected objects are implemented using the Alsys passive task construct which ensures critical regions around resources and execution of code. PSER operations are thus mapped to an entry in the Alsys passive task and this ensures complience with the HRT-Hood method. 17

24 7 ESF and UCF This section very briefly describes that the purpose is with including the Execution Skeleton File (ESF) and the User Configuration File (UCF) in the design and what the entries in the two files mean. The complete ESF and UCF files are included in the appendix of the ADD. In the eletronic version of the (HRT-Hood tool) projects, ESF file parts have been included without timing characteristics in all Terminal Object Descriptions for the relevant objects. 7.1 ESF Every terminal object which is not a Gen Act Param object, a passive object or a object without an OBCS has an entry in the ESF. An entry might e.g. look like the following: PROTECTED Ground_IF.The_Ground_IF.The_Receiver.Event_Buffer.Queue_Task TYPE SYNCHRO ENTRY Deposit WCET 96, 0, 0 BARRIER WCET 6, 1, 0 ENTRY Extract WCET 76, 0, 0 END Ground_IF.The_Ground_IF.The_Receiver.Event_Buffer.Queue_Task which says that object Ground IF.The Ground IF.The Receiver.Event Buffer.Queue Task is a synchronised protected object (which in fact manages the envokation queue to sporadic objects). It has to operations Deposit and Extract. The operation Deposit has a worst-case execution time (WCET) of 96 clock cycles, 0 memory reads and 0 memory writes. The operation Extract might have a barrier which takes 6 clock cycles to evaluate and include one read from memory. 7.2 UCF Every active terminal object have additionally to the ESF an entry in the UCF. Active objects are either cyclic, sporadic or active, but we haven t any active terminal objects in the design. A UCF entry might look like: THREAD Packet_Router.Packet_Forwarder.The_Sporadic_Task CRITICALITY Hard MINIMUM 71_425_ packets per second DEADLINE 10_000_0 END Which states that the terminal sporadic object Packet Router.Packet Forwarder.The Sporadic Task has a hard deadline (which means that no overrun of deadline is allowed). Has a minimum inter-arrival time of clock cycles (10 Mhz / 14 packets). The deadline is the time that all activities in the object must be completed. 18