Specification and Quality Assurance of Timing Constraints in Real-time Systems Development

SOFTWARE—PRACTICE AND EXPERIENCE, VOL. 22( 11), 963–984 (NOVEMBER 1992)Specification and Quality Assurance ofTiming Constraints in Real-time SystemsDevelopmentCHIH-CHENG LIEN* AND CHIEN-CHIAO YANGDepartment of Electronic Engineering, National Taiwan Institute of Technology,43, Keelung Road, Section 4, Taipei 10772, Taiwan, R. O. C.SUMMARYA representation for specifying the timing constraints of real-time systems is presented. Four parts of descriptions in a timing constraint: the path of events, timer, types of constraints and quantities of time, are explained. Under the relations among the paths, the hierarchical and network structures can be conducted. The former can be associated with the structure resulting from applying top-down decompo-sition in software development. The latter represents the execution dependence of the paths. Based upon these clear and manageable structures, the completeness and consistency of timing constraints specification can be rigorously analysed. Thus, the quality of the specification of timing constraints can be improved during software development. A frame-like software requirements specification language (FSRSL) is extended to specify timing constraints and the related descriptions in the paper.KEY WORDS Real-time systems Refinement Specification Timing constraintsINTRODUCTIONReal-time computing systems have appeared more widely in recent times, 1 for example in laboratory experiments, command-and-control, process control plants and robotics. Consideration of timing constraints plays an important role in real-time systems development. From experience, a requirements specification is introduced to2’3 Thus, to specify timing constraints improve the success of system development.during real-time systems development is necessary and important.In the traditional style, timing constraints are informally described during systems development. 4 They must be interpreted by people and cannot be analysed with assistance from computers. Thus, informal specification makes the development complex and is not encouraged. Formal specification, on the other hand, is encour-aged in software development.5 Based upon this approach, many design methods and computer-aided tools can be developed to support higher quality software development.Among using formal representations in timing constraints, some approaches mix the declarations of timing constraints with the specification of functional requirements * To whom all correspondence should be addressed. Address: P.O. Box 90-74, Taipei, Taiwan.0038–0644/92/110963–22$16.00Received 19 October 1990© 1992 by John Wiley & Sons, Ltd.Revised 10 July 1992964 C.-C. LIEN AND C.-C. YANGthroughout a system specification.For example, many approaches insert timing constraints sequentially into the functional specifications. 6–11 The resulting specifi-cations are sequential and unstructured. Hence, tracing and interpreting these speci-fications is complicated. This phenomenon reveals that separation of concerns about the timing constraints and the functional requirement is encouraged.In this paper, a formal representation for timing constraints specification is pre-sented. A frame-based software requirements specification language (FSRSL) is extended to specify these constraints. FSRSL is a formal and an executable specifi-cation language which has been presented in Reference12. Its prototypes are executable if supported by a software base of reusable components .2’13,14 In FSRSL, functional and non-functional requirements are separately addressed. Thus, separ-ation of concerns for the functional specification and timing constraints specification is achieved.Both top-down decomposition and top-down refinement are the major methods in the early phases of software development, such as requirements analysis, prototyp-ing, and design.15 In applying these two methods, functional requirements are usually decomposed, or made more detailed, respectively. If applying these methods to functional requirements and to timing constraints are compatible, the experience in manipulating functional requirements can be used for the manipulation of timing constraints. This versatility prompts the user acceptability of timing constraints considerations. This is beneficial to real-time system development. FSRSL is a wide-spectrum specification language underlying which is a unified model to control the relations of specifications produced by top-down decomposition and refinement during software development. This permits both the customer and software devel-opers to assert these timing constraints in a more structured fashion.Some approaches use the specification of timing constraints to predict and study timing performance of a system.6’7’8’11 They usually assume that the timing constraints specification is correct. Hence, few of them have dealt with the qualities of the specification of timing constraints. However, several timing constraints can be speci-fied in a specification during software development. Thus, these timing constraints may be not complete or consistent. Especially, applying top-down decomposition and refinement to software development usually causes some inconsistency between the original and the modified specifications. In such a case, the investigation of timing characteristics based on the specifications which are not complete or consistent can be defective or of no value. Therefore, some qualities of the specifications of timing constraints, such as correctness, completeness and consistency, should be analysed and improved before more detailed studying of the timing characteristics of a system.In this paper, the correctness, completeness and consistency among the specified timing constraints are defined. Then, these qualities are analysed in order to improve the qualities of the specifications. Since a formal and structured specification is used, these qualities can be analysed more rigorously than if an informal and unstructured specification is used. Thus, our approach allows the developer to deal with the anomaly of the timing constraints specification before further analysis of the timing performance.Major implementation of the analysis of qualities is based on rule-based program-ming. This approach enhances the extension of new analysing rules for conducting quality assurance. To analyse the quality of a specification, some descriptions areTIMING CONSTRAINTS IN REAL-TIME SYSTEMS965 used to describe the analysis procedures and rules. Usually, the representation ofthese descriptions is different from the representation of system requirements. Thus, the software developer has to learn two different styles of representation. This increases the load for the software developer and decreases the usage of quality analysis. In this research, not only the specifications of the functional and non-functional requirements, but also the rules for analysing the qualities of the con-straints, are uniformly written in FSRSL. This uniform representation to describe the related information in our approach can improve the acceptance and under-standability of our work for the software developer.The remainder of this paper starts with an overview of FSRSL. Then the represen-tation for specifying timing constraints is explained. Further, the qualities of timing constraints such as correctness, completeness and consistency, are defined and analysed. Some related implementation and notations concerning this research are also shown. Finally, conclusions are drawn.FSRSLThe FSRSL specification language has been developed to describe the functional and non-functional requirements produced from requirements analysis. 12 It adopts some important ideas from other useful methods and techniques such as frame representation,16 structured analysis (SA), 17 functional programming 18 and struc-tured programming,19 to support software development.In general, an application system specified in FSRSL is composed of several frames. These frames record the declarative and procedural information about this system. Five basic types of frames—process, data, signal, control and assertion—are derived to specify the information of a software system and its components. A process frame denotes an action in a system. Its input and output can be data or signals. Data records the result of a process, and signals are used to trigger processes or controls. The details of a datum, which can flow between processes, is described using a data frame. Thus, the first two types of frames are designated to correspond with the ‘data’ and ‘transform’ in the SA model. The detailed description of a signal is recorded with a signal frame. The complex control activities related to a job ,are gathered and specified with a control frame. Hence, only the signals are the outputs of a control. Finally, the assertion frames are designated to assert facts and assump-tions in software development. The above ideas extend the SA model to an extended real time structured analysis (ERTSA) model.12’20 Here, in our viewpoint, functions which have been designed by other people or systems are special cases of the processes. For example, if a function, implemented in C to sort positive integers, is used in a design, it can be viewed just as a process. Whether the other types of frames are needed is decided on and extended by the user.A prototype of a patient appointment system, detailed below, is used to illustrate the system analysis using ERTSA. Such a system usually deals with the appointments of patients first, and then backs up the appointment data into a file or a database. Some control activities control these two processes. In the initial stage of the appointment, we gather and request the data needed for the patient record. Then, the data is rearranged into a patient record. After a certain number of appointment records are produced, the system has to back them up. The sequence of the above processes is controlled by a control process which outputs control signals as required.966 C.-C. LIEN AND C.-C. YANGFigure 1. ERTSA’s representation of a patient appointment systemFigure 1shows the resulting graphical representation. There are five types of descrip-tions in this figure: data, process, signal, control and assertion. They are represented by solid lines, circles, bold solid lines, bold circles and dotted lines, respectively. Likewise in the SA, open boxes are data stores.By splitting the work of gathering the patient’s data and arranging the appointment record, the process Daily Patient Appointment can be decomposed into two subpro-cesses Appointment Application and Appointment Arrangement. The graphical represen-tation of the relationships of these two subprocesses is given in Figure 2.Figure 2. Two processes resulting from decomposing the process Daily PatientAppointmentTIMING CONSTRAINTS IN REAL-TIME SYSTEMS 967To backup the related data, we can simply copy them into a file, or control them using databases. An instance of the implementation for these control activities could be in a particular language, e.g. Ada, C, Pascal, etc. Thus, the decomposition tree of this example system is like Figure 3, where the circles denote processes and the arcs are labelled with some hierarchical relations such as ako, apo and isa. These relations are discussed below. The description of timing constraints, min and max,will be discussed in the next section. A brief description of the processes in Figure 3is as follows:pc a :system of patient appointments p c a,a :backup the data of patient appointments p c a.b :daily patient appointment p c a.c :control the activities of this system p c a.a.a :database consideration in backup p c a.b.a :gather the data of appointments p c a.b.b :arrange the data of appointments p c a.c.a :implementation of control activities by C.In gathering appointment data, outpatient and inpatient services need to be considered. In the first service, the doctor makes a diagnosis and releases the patient.In the second, the patient has to be checked into a room for a few days. Thus, for the outpatient service, the data of the department need to be gathered. For the inpatient service, the data of the department and the room need to be gathered.Sometimes the data were gathered already for the last appointment, and we do not have to gather them again. Consequently, there are four events, e 1, e 2, e 3 and e 4,described below; the execution dependency of these events is shown in Figure 4.e 1:e 2:e 3:e 4:begin doing appointment gather department data gather rooms data gathered appointment data already.The three abstract relations of knowledge structure among the frames are classifi-cation, generalization and aggregation. Classification denotes the common attributesFigure 3. A decomposition hierarchy of processes968 C.-C. LIEN AND C.-C. YANGFigure 4. A decomposition hierarchy of processeswhich are shared in the set of individual instances by creating a new class. Generaliz-ation captures the common specification from the set of classes, and makes a more general class. Aggregation treats a collection of entities as a single entity. Three reserved words: is-a, a-kind-of and a-part-of, which can be simplified to isa, ako and apo, are used to represent these three asymmetric relations of classification, generalization and aggregation, respectively. The properties of inheritance among frames allow the low-level entities to share information with their high-level entities. In FSRSL, the inheritance in a hierarchical relation can be strict or default. For strict inheritance, an instance will keep all the properties of its parent, whereas default inheritance allows an instance to override some properties of its parent. These abstract relations provide the ability to apply the techniques of top-down decomposition and refinement in the ERTSA model. The relations of classification, generalization and aggregation will be presented in the implementation, refinement and decomposition of a system, respectively.The syntax of a frame is similar to the, definition of frame representation in AI. It includes the frame name, slot, slot’s value, etc., as described in Reference 16. Each frame uses a unique frame name to represent its themes. Its type should also be specified. Its detailed contents are recorded in its slots. The logical and control information of a frame are specified in a ‘procedure’ slot, and by a function-like expression mixed with the general control constructs: sequence, if–them, and while–do. A general view of a frame in FSRSL is shown in Figure5.To illustrate the representation of FSRSL, Figure6 shows a process frame in a hospital patient appointment system. From the slot apo in this Figure, we know that the process AppointmentArrangement is a part of the process Daily PatientAppointment. This is a result of applying a top-down decomposition to the process DailyPatient-Appointment. The slots DataIn, ControlIn, Storeln and StoreOut are used to describe the interface relationships in the ERTSA model. The slot procedure specifies the activities of process AppointmentArrangement, in which accept is a logical flag and update, addint and display are the function names.For more illustration, the following specification is for process pc:a.a.aprocess: pc.a.a.a;ako: ″ BackupPatientAppointment ″ ;implement-consideration:relational-database;endframeHeading slot Attributesslots Ending slot TIMING CONSTRAINTS IN REAL-TIME SYSTEMSTime of frames: assertion, control. data, process, signal.Frame name of this frame.Information about knowledge structure:isa (is-a), ako (a-kind-of ), apo (a-part-of)Information about design method:data attributes: . . . -funtional interface:ControlIn, ControlOut, DataIn, DataOut, StoreIn,StoreOut functional activities:operational commands; like the mini-spec in the SAsignal contentscontrol activitiesassertion contentsPhases of life cycle:requirements analysis, design, . . .Nonfunctional requirements:documents, reliability, user friendly, . . .Other information for analysis or validation:InvolvedFunc, Producer, Consumer, . . .Reserved word “endframe” to end this frame969 Figure 5. A general view of a frame in FSRSLprocess: AppointmentArrangement;ape: Daily Patient Appointment;DataIn: AppMessage;ControlIn: accept:StoreIn: AppointmentIndex;StoreOut: AppointmentRecord, AppointmentIndex;InvolvedFunc: addint, display, update;procedure:ifacceptthenupdate(Appointment Record, AppMessage ),addint (AppointmentIndex, 1),display( “appointment complete”),endif;endframeFigure 6. A specification of a process in FSRSLEven though the specification for process pca.a.a is very simple! it is effective sinceit inherits the specification for BackupPatientAppointment. Thus, the interface and procedure of process pca.a.acan be traced from the specification for BackupPatient-Appointment. Furthermore, the partial specification for process pc a.c.a is as follows: process: pc.a.c.a;isa: ″ ControlPatientAppointment ″;procedure:970 C.-C. LIEN AND C.-C.pc_a_c_a(int start, int stop, ..., FILE YANG*appointmentindex){.};endframeLike the inheritance effect in the specification for process pc a.a.a , the interface and procedure of process pc a.c.a can be traced from the specification for ControlPatient-Appointment. However, the contents of slot procedure are to be defined again, and the specification of slot procedure is not used in this specification. The procedure name pc_a_c_a is derived from the frame name pa a.c.a . since the name pc .a.c.a is not allowable in C. The detailed characteristics and applications of FSRSL can be found in Reference 12.THE SPECIFICATION OF TIMING CONSTRAINTSFirst in this section, the representation of timing constraints is explained. Then,the relations among the constraints are discussed. Finally, some related work is explained.Specifying timing constraintsFrom our experience, four parts are necessary for specifying a timing constraint:the applying range, types of constraints, reference timing systems and quantities of time. The last three parts yield an n -tuple( TS,CT,Q,Q,... )where TS is the set of timers, { ts l , ts 2,. . .}, CT is the set of types of the constraint,{ ct 1, ct 2,...} and Q is the set of quantities, { q 1,q 2,... }, q i ≥ 0 ∧ q i ∈ R.An applying range can have as many attributes as does the above n-tuple, and separates two attributes with a semicolon. Thus, a general form for specifying a timing constraint, which has the applying range, r, can be represented as follows:( r ;ts 1,ct 1, q 11,..., q 11 ; . . .; ts i .ct i , q i 1,.., q in ;ts j ,ct j ,q j 1,..., q jm ;...)(1)Note that { ct 1, q ll , . . . , q l k }, { ct i , q i l , . . ., q in } and { ct j ,q j 1, . . ., q jm } correspond to timing systems ts 1,ts i , and ts j , respectively. The quantities are specified by non-negative real numbers. Before any further discussion of these parts of form ( 1 ) in the following, a general form for specifying a timing constraint used in our approach has to be discussed. In form (1), all of the attributes of an applying range are gathered into one form. This style, however, may be too concise to conveniently use for a software developer. For convenient usage, one developer may split form (1) into the following:( r;ts 1,ct 1, q 11,..., q, 1 k )( r ; ts i ,ct i , q i 1, . . ., q in )972 C.-C. LIEN AND C.-C. YANGAnother important aspect of timing constraints is their types. If a constraint asserts that the desired measured quantity of a development instance is less than or equal to the specified quantity, it is a maximum constraint. On the other hand, if a constraint asserts that the desired measured quantity is greater than or equal to the specified quantity, it is a minimum constraint.Sometimes, for simplicity, some usual types of timing constraint such as waiting time and deadline are rewritten as follows:min_tc_# ( r, q min __tc )(3)max_tc_# ( r, q max_ tc )(4)where the waiting time shows a time interval in which a path of events cannot be finished denoted by min_ tc_ #( ). The deadline of a path referring to the start event is shown by max _tc_ #( ). Here, as in form (2), the symbol # is used to index the constraints.There are two types of specifications of quantities: parametrized and numerical form. The former is represented by a polynomial of procedural expressions, e.g. get-a-datum + write-a-datum-into-a-file. The latter is shown by a non-negative real number,e.g. 7, with units according to the corresponding timing system.In forms (3) and (4), all the quantities of time in the constraints refer to the default timer which is reset at the completion of the first event of a path. However,in some scheduling, we have to specify the constraints referring to other timing systems, e.g. the global timer. For example, to arrange the daily work of a person,global time is also used as well as the elapsed time of each job. Thus, in the maximum constraint, a specified path of jobs must be finished under the quantities specified within a default timer and within a global timer. Using a term of ‘global-timer’ in form (2), the following form could be used to specify a constraint in which some quantities refer to the global timer:tc _#( r; ct l , q ll , . . ., q l1 , . . ., global-timer, ct i , q i l , . . .,q in , ct j , q j 1, . . ., q jm ; ...)(5)Now in form (5), the constraint type ct i refers to the global timer, and the constraints ct l and ct j refer to the time which starts at the first event. In addition, { qi l , . . . , q in }and { q ll , . . . , q 1 k , q j 1, . . . ,q jm } are with respect to the global timer and the default timer.To illustrate that the general form (2) is beneficial for representing timing con-straints, we will define new types of timing constraints by introducing the two terms ‘l-bound’ and ‘r-bound’, in which each term corresponds to a time quantity. Two quantities corresponding to (l-bound, r-bound) will make a time interval in which the left and right boundaries correspond to the quantities ‘l-bound’ and ‘r-bound’,respectively. Now if a constraint has several intervals, then the following is a graphical representation of a time axis, where q i are the indexed time quantities:Let a type of constraint be named every-interval, which defines the ending event of the applying range which must be finished in all the above bold intervals. ThisTIMING CONSTRAINTS IN REAL-TIME SYSTEMS 973implies that the timing quantities which are index by odd and even number are left and right boundaries, respectively.To illustrate the usage of this constraint, for example, a hospital has to have two meetings every day in order to plan and check the activities in the morning and evening, respectively. Then, the constraint (< daily works start, start meeting >;every-interval, 10 minutes, 20 minutes, 7 hours, 30 minutes to 8 hours) can be used to handle the timing for starting the meeting. Certainly, some emergent diagnosis and checking of patients can also use this type of constraint to control the checking work in time. As we can see, this type of constraint is not the same as the constraints in the periodic events because the lengths of such intervals are not identical. Of course, the developers can allow the ending event to be just finished in some intervals in order to synchronize with other events, and use different terms, e.g. ‘commun-interval’, to name the type of the constraint. Therefore, the general form is suitable to describe the discussed constraints, and also encourages software developers to create other types of timing constraints.Relations among timing constraintsThere exist some relations in the timing constraints of a system. In FSRSL, we have introduced three asymmetric relations in functional requirements: classification,generalization and aggregation. Adapting the definition of these relations, we will define the relations between the paths in the following and assume that the events specified in the paths are in the same order. A path i is an a-kind-of path to its general path j, if the set of events in path j is a proper subset of the set events in path i and these paths have the same start and end events. A path i is an a-part-of path to its general path j if the set of events in path i is a proper subset of the set of events in path j and does not have the same start and end events. A path is an is-a path to another path if the above two paths have the same path specifications.To illustrate these relations, for example, path < e l , e 2, e 3 > is an a-kind-of path to path < e l , e 3 >, where e l , e 2 and e 3 are different events and do not correspond to the events in Figure 4. Furthermore, path < e l , e 2 > is a-part-of path < e l , e 2, e 3 >.The path < e l , e 2 > is-a path < e l , e 2 >.The last definition seems to be strange.However, the same paths may be followed by different constraint types and quantities specification. Thus, the definition of the relation is-a between paths is necessary for checking the qualities of constraints specification. We can use the nodes and arcs in a directed graph to represent the paths and their relations, respectively. Since there exists a one-to-one mapping between the constraints and their applying range, the above relations also exist in the constraints. This shows that the decomposition and refinement methods in the processes and paths are the same, but the related data are ing the abstract relations,the information produced by applying top-down decomposition and refinement to a system may be described. For example, Figure 3presents a hierarchy of processes obtained from an instance of top-down decompo-sition and refinement. Figure 7 is a version of Figure 3 in the representation of the paths, where a process i can be denoted by its start and end events. In general, an event in a path may happen in a process or other processes. In this case, the nodes in Figure 3 are not suitable for representing timing constraints since they are not able to map the events which happened in two processes. Thus, using the nodes of974 C.-C. LIEN AND C.-C. YANGFigure 7. A decomposition and refinement hierarchy of timing constraintsa graph in this research to represent the paths, e.g. in Figure 7, is more suitable in expressing the decomposition and refinement of timing constraints rather than to represent the processes. The following are the straints in Figures 3 and 7:detailed - descriptions of timing con-tc_# 1tc_# 2tc_# 3tc_# 4tc_# 5tc_# 6tc_# 7tc_# 8Note that three primitive constructs can be designated, namely compound_ event ( e 1, e 2, . ..), exclusive_event ( e 1, e 2, . ..) and only ( e l , e 2, . ..). to improve the expressive power of a path. The first primitive construct denotes a set of events { e l , e 2, . . . },and its reference time is the point at which all the specified events have finished.Sometimes the sequence of some events in the paths is not (or need not be) very clear, and this primitive construct can be used to describe this case. The second primitive construct shows that the specified events are not contained in its correspon-ding path. It can be used to distinguish two paths which have only a few different events, e.g. the same endpoints, but some different middle points. The last primitive construct is used to specialize a part of the path which has only the specified events.For simplicity, only () is rewritten as %(). Thus, < e i , e j > maybe a general description which includes all the paths from e i to e j , but % < e i , e j > includes only one path from e i to e j directly. In particular, referring to Figure 4, the representation < e l , compound_event ( e 2, e 3), e 4 > specifies path < e l , e 2, e 3, e 4 >, but not < e l , e 3, e 4 >. The representation < e l , exclusive_event ( e 3), e 4 > specifies two paths, < e l , e 2, e 4 > and < e l , e 4 >.The representation % < e l , e 4 > specifies one path < e l , e 4 > only. Involving these primitive constructs in the definition of the above relations in timing constraints is straightforward. The first two primitives denote two events with the special types, and are viewed as the events in the path.In addition, % < e i , e j > is an ako path of the path < e i , e j >.。