Construction of Global Finite State Machine for Testing ... - CiteSeerX

Construction of Global Finite State Machine for Testing Task Interactions written in Message Sequence Charts

∗

Nam Hee Lee, Tai Hyo Kim and Sung Deok Cha Division of Computer Science and AITrc Department of Electrical Engineering and Computer Science, KAIST 373-1, Gusung-Dong, Yusung-Gu, Daejon, Korea {nhlee,taihyo,cha}@salmosa.kaist.ac.kr ABSTRACT

Keywords

Integration testing of embedded software is difficult because such software tends to be large and complex; it is often structured as a set of tasks whose interaction patterns can be arbitrary and nondeterministic; it is subject to frequent changes while being tested; and testing period must be minimized since the product’s life-time is short. In order to conduct integration testing in a cost-effective manner, it is essential that requirements are captured in precise notation and that test cases are automatically generated and executed whenever possible.

Integration Testing, Message Sequence Charts, Task Interaction

In this paper, we demonstrate how to generate test cases from a set of Message Sequence Charts (MSCs) by constructing a semantically equivalent global finite state machine (GFSM). Test cases are expressed as a sequence of messages to be exchanged among various system entities. When transforming complex and hierarchical MSCs to a GFSM, state explosion problem is often encountered. When constructing a GFSM, we achieved significant reduction in the number of states and transitions by generating only the feasible sequences. Such reduction was possible because embedded software we used as the case study, digital TV application software, had known and well-defined initial state. We developed a graphical toolset to edit MSCs and automatically generate test cases. Users describe the required functionalities in scenarios, and test cases are automatically generated from the GFSM according to the state and transition coverage criteria. We applied the proposed approach to specify and test a substantial portion of embedded software running on a digital TV and were able to detect an error, previously unknown to the developers, that occurred due to a subtle race condition among tasks. ∗ This work has been partially supported by the Advanced Information Technology Research Center (AITrc).

1.

INTRODUCTION

Usage of software in controlling embedded systems has become popular. Such trend is especially true in home appliances where embedded software is usually quite large in size and complex in requirements. For example, there are over 800,000 lines of C and Java application code running on various microprocessors in a modern digital TV, and such figure excludes the size of software implementing a real-time operating system, library routines, and a Java virtual machine. Other embedded systems that are heavily softwaredependent include cell phones, web phones, and automobiles. Such embedded software must obviously satisfy an extremely high-level of quality assurance requirements, and manufacturers must perform as rigorous, cost-effective, and automated software quality assurance tasks as possible to remain competitive. Testing of embedded software is difficult because: (1) Software is usually large in size and complex in requirements; (2) Time available to test embedded software is usually quite limited due to relatively short life-time of the products. Manufacturers are under great and continuous market pressure to keep introducing new models with new or enhanced features. Although much of basic software may be reused from one model to the next, testing becomes a critical task if a large amount of new code have been newly developed. Even if a relatively small amount of code is new to the system, integration testing task does not become any easier because new code must be shown to work well with old code; (3) Software might be subject to frequent changes to meet various customer demands even as the system goes through integration testing; and (4) Embedded software usually consists of a large number of concurrently executing and interacting tasks each of which is executed at different intervals, under different conditions, and with different timing requirements. Therefore, embedded software testing must be automated as possible since the cost-effectiveness of testing is of critical concern to maintain the competitive edge. Among different phases in embedded software testing, we’re most interested in integration testing where interfaces and interactions among various subsystems are examined. When conducting integration testing, modules are assumed to have

been developed and adequately tested. Testers responsible for integration testing are usually concerned with the order in which various modules are “combined” and tested. However, when developing embedded software, especially in the home appliance market, it is often impractical to first completely develop all the component modules and integrate them later. Tasks implementing the core functionalities are usually developed first, and other modules are added later. During the development process, requirements tend to be frequently modified or extended. Therefore, traditional waterfall-like process model where the required behavior of all the tasks are fully specified and analyzed prior to entering design and coding phase is simply unrealistic. Although natural languages are most frequently used to describe requirements, it is impossible to perform rigorous and formal analysis on the requirements for completeness and consistency unless the requirements are written in a formal notation. Furthermore, automated generation of specificationbased test cases would be impossible if requirements are written informally. There are several formal specification languages that have been successfully applied on many and large-scale industrial projects, e.g. Statecharts [1], SDL [2], Petri Nets [3], Message Sequence Charts (MSCs) [4]. When conducting integration testing, state-based description of task behavior is less likely to be effective when compared to scenario-based specification where partial but logically independent requirements are documented separately. This is especially true if requirements are likely subject to modification. For example, let’s assume that the current version of digital TV software, structured as a set of tasks, can successfully deal with an external signal (or event) named A, and that a new signal (or event) named B must also be supported. Rather than analyzing the entire state-based models and updating them to correctly process the signal B, it is desirable to separately document how the signal B must be handled by the relevant system entities. If, for some reason, support for the signal B is to be dropped or modified in later models, requirement management and test case generation become much simpler in a scenario-based specification compared to state-based models of requirements. MSCs is an attractive formalism when specifying requirements related to integration testing of embedded and reactive software because (1) MSCs is an internationally standardized language, and MSCs’ graphical notations are easy to understand; (2) MSCs constructs include features to express complex requirements in a hierarchical manner; (3) its formal semantics are well-defined; and (4)various system entities are shown separately and the interactions among them are expressed naturally and explicitly. Research on test case generation based on MSCs has been actively studied in the past. However, MSCs has been used to determine whether or not the test sequences, identified using other means, were feasible. For example, in [5], test sequences were generated from the SDL model, and MSCs were used to determine if it was a feasible sequence or not. [6] used basic MSCs to identify potentially concurrent events and used such information to generate test sequences. However, system model was divided into IUT (Implementation under test) and ENV (Environment), and interactions among

various tasks included in the IUT were ignored. That is, test cases consist of externally visible input and output events only, and flaws related to incorrect internal task interactions would be difficult to detect. The proposed approach is illustrated in Figure 1. Interaction scenarios and various system state information are expressed in basic MSCs (bMSCs). While each scenario describes partial requirement, global system behavior must be obtained and analyzed by combining various MSCs in order to generate test cases. Therefore, we choose to formalize semantics of MSC formalism and to transform a set of bMSCs into a behavior automata and ultimately to a global finite state machine (GFSM) from which test cases are generated. In order to reduce the states of the GFSM, an initial state of the system is used to generate only the feasible states from that. Transitions in the GFSM are created only when there are changes in the values of the system’s state variables.

Figure 1: Our Approach Embedded software accepts data or command inputs from one or more sources, and the outputs are generated by processing the inputs given the current system state. The primary goal of integration testing in embedded software is to determine if the system correctly reacts to various external events. In general, there can be arbitrarily large number and complex patterns - including timing intervals - of external events the system must process. In principle, while the system is busy responding to an external event, other events will occur. From the tester’s viewpoint, it means that while an MSC is activated and messages are being exchanged among various tasks, other MSCs can and need to be activated. However, if the system can be reasonably assumed to process inputs at a rate much faster than the minimum interarrival time between the inputs, internal processing can be assumed to occur in zero-time. Such assumption is generally referred to as the synchrony hypothesis [1], and formalisms designed to capture behavior of reactive systems (e.g., Statecharts) commonly adopt such assumption. Our approach makes the similar assumption in that each state of the GFSM captures the system configuration reachable after the system has completely processed an external

event. As the unstable configurations of the system are excluded in the GFSM, we are able to achieve significant reduction on the number of states and transitions. In addition, test driver has been designed to “remember” all the external events that occurred while the system makes a transition from one stable configuration to another.

msc R1 I1

I2

when

msc R2 I1

n = 1

when

n = 2

e7

d

The rest of the paper is organized as the following. In section 2, we briefly review syntax and semantics of MSCs. In section 3, we explain algorithms used to transform a set of MSCs to a semantically equivalent GFSM. In section 4, using an embedded software running on a digital TV, we illustrate how to apply the proposed approach to automatically generate test cases. Finally, section 5 concludes the paper.

I2

e

e8

n = 2

n = 1

e9

(a) R1

(b) R2

Figure 3: R1 and R2 bMSCs

2.

MESSAGE SEQUENCE CHARTS

An MSC describes partial scenario on how various system entities (instances), logically or physically distinct, interact by exchanging messages [4]. The life-line of an entity is visually represented by a vertical axis, while the messages are drawn as arrows connecting these life-lines. For example, MSC ‘M’, shown in Figure 2, contains four instances, named ‘E1’, ‘I1’, ‘I2’ and ‘E2’, and three messages, ‘a’, ‘b’ and ‘c’. When the MSC ‘M’ is activated, messages ‘a’ and ‘b’ can be sent. Two messages have no implied order of execution because the MSC ‘M’ does not exhibit causal dependency between them. However, the ‘c’ message sending must occur after the ‘b’ message receipt because there are message exchange sequences that are temporally ordered in the same instance. msc M I2

I1

E1 0

0

E2

0

a

0

b 1

1

c

1 2

1 2

alt R1 R2 2

3

3

In this paper, we make the following assumptions for specifying and interpreting MSCs: First, activation conditions, showing in each bMSC, are assumed to have been completely and consistently specified. That is, it is possible to statically and uniquely determine which bMSC is activated based solely on the value of variables used in the activation condition. This assumption is reasonable because incomplete or inconsistent activation conditions can be automatically detected. Second, we assume that no bMSC is referenced recursively. Otherwise, our algorithm to transform MSCs to a GFSM would never terminate. We have not yet found situations under which it is essential to allow recursive referencing of bMSCs. Finally, we use synchronous concatenation [7] between the referencing bMSC and the referenced bMSC. It means that the referenced bMSC must be enabled after all messages in the referencing bMSC are exchanged. Before describing the formal definition of MSCs and translation algorithms, we define basic notations. A set of ‘Instance’, tasks, is represented by P . A set of events and labels are represented by E and Σ, respectively. The ‘Message’ events are represented by E M , and the ‘Condition’ events are represented by E C = E Ca ∪ E Cs , where E Ca is the activation condition and E Cs is change made to the system states. ‘Reference’, ‘Opt Inline’, ‘Loop Inline’ and ‘Alt Inline’ events are represented by E R , E O , E L and E A , respectively. Consequently, the events set E is defined to E M ∪ E C ∪ E R ∪ E O ∪ E L ∪ E A . The label set Σ consists of ΣR ∪ ΣP ∪ ΣM ∪ ΣC , where ΣR is the name of bMSCs, ΣP is ‘Instance’, ΣM is ‘Message’, and ΣC is ‘Condition’. The set of state variables is V .

2

Figure 2: MSC M In addition to simple message exchanges, MSCs standard provides various structuring mechanisms. For example, the ‘alt’ in-line expression in the MSC ‘M’ indicates that after exchanging three messages, either ‘R1’ or ‘R2’ bMSC is selectively activated. The exact conditions under which bMSC is activated are specified in the referenced bMSCs. Figure 3 illustrates an example.

Definition 1 (MSC Structure). Overall structure of specification consists of five tuples M SC = (S, s0 , ΣR , nr , Sr ) where • S is a finite set of bMSCs. • s0 ∈ S is the top level scenario. • ΣR is a set of names. • nr : S 7→ ΣR is a bMSC mapping function of the names to each bMSC.

• Sr = {(s1 , s2 ) | s1 , s2 ∈ S} is a reference relation between bMSCs. Definition 2 (bMSC). Each bMSC Sp ∈ S consists of six tuples Sp = (Ps , Es , Σs , ps , ls , hs ) where • Ps ⊆ P is a finite set of instances. • Es ⊆ E is a finite set of events. • Σs ⊆ Σ is a finite set of labels. • ps : Es 7→ 2Ps is an instance mapping function for each events to instances. • ls : (Ps ∪ Es ) 7→ Σs is a labelling function for each instances and events. S • hs : hPs is an ordering relation between events, where hPs = {(e1 , e2 ) | e1 , e2 ∈ Es } represents the ordering relation in an instance. In the bMSC ‘R1’ of Figure 3, two instances and three events are used. e7 is a scenario activation event, e8 is a message event, and e9 is a state change event. For the instance ‘I1’, the visual order of events is {(e7 ,e8 ), (e8 ,e9 )}.

3.

SEMANTIC INTERPRETATION OF MSCS

The first step in generating a GFSM is to define behavior automata BA for a bMSC by assigning non-negative and monotonically increasing location indicators for each event appearing in the bMSC. For example, in Figure 2, bMSC ‘M’ is in its initial location [0,0,0,0] for each instance. Event ‘a’ or ‘b’ may occur, and the system enters the location [1,1,0,0] or [0,0,1,1], respectively, upon completing the message exchange. Figure 4 is the behavior automata generated from the bMSC ‘M’. [1,1,0,0]

a

b

[0,0,0,0]

[1,1,1,1]

c

[1,2,2,1]

alt

[2,3,3,2]

Algorithm 1 (BA Extracting Algorithm). 1: Q = ∅; δ = ∅; 2: q0 = [0,0,· · · ]; 3: push(Stack, q0 ); 4: while (Stack is not empty) 5: conf = pop(Stack); 6: Q ← Q ∪ conf; 7: for each e ∈ Es 8: if (F(conf, e)==true) 9: δ ← δ∪ (conf, e, A(conf, e)); 10: if (A(conf, e) 6∈ Q) push(Stack, A(conf, e)); 11: end if 12: end for 13: end while

An algorithm to construct a behavior automata from a bMSC starts by initializing Q and δ, states and transitions, respectively, to empty sets (line 1). The initial state of the BA is defined, and it’s pushed onto stack (lines 2 and 3). The algorithm then examines which event may occur in the current system configuration (lines 7 and 8). The function F determines if each event e is enabled or not. For each of the enabled functions, δ, a set of transitions, is updated to reflect the source and destination states as well as the triggering transition (line 9). The advance function A is used to compute the destination state the system enters when the event is processed. If the newly identified destination state had not been previously analyzed, information on the new state is kept so that the same analysis can be repeated later (line 10). The algorithm needs to be extended to properly handle various in-line expressions such as reference, opt, alt, or loop constructs. This is accomplished by combining BAs separately generated from the corresponding bMSCs. We refer to such an automata as the unfolded behavior automata or UBA in short. Figure 5 visually illustrates how various inline expressions are dealt with. It should be noted that  transitions, scenario activation conditions, and loop counters are used as needed when combining several BAs. The use of  transition is appropriate in unfolding because we assumed the synchronous concatenation [7].

a

b [0,0,1,1]

Figure 4: Behavior Automata for MSC M

Definition 3. Behavior automata is formally defined as five tuples BA = (Q, ΣBA , δ, q0 , F ) where • Q is a finite set of states. Each state is defined in terms of instance’s location indicators. • ΣBA = Es is a finite set of events, and it is same as the events set of Sp . • δ ⊆ Q × ΣBA × Q is a set of transitions. • q0 ∈ Q is a initial state. • F ∈ Q is a finite set of final states.

Figure 6 represents the combined UBA. It should be noted that the UBA is annotated with path information. For example, the system enters the state ‘M.R1 [1,1]’, location [1,1] in the bMSC ‘R1’ when the value of ‘n’ is 1. We use state variables and their values such that transitions are created only when the values of state variables are changed. Therefore, a state in the GFSM is defined as the set of values of all the system state variables. Likewise, a transition represents an ordered sequence of messages that must be exchanged. It should be noted that multiple transitions are created if there are unordered and potentially concurrent message exchanges. Definition 4 (GFSM). GFSM consists of four tuples GF SM = (SGF SM , sGF SM0 , ΣGF SM , TGF SM ) where • SGF SM is a finite set of states.

(a) ref

(b) opt

Figure 6: UBA for MSC M

(c) loop

(d) alt

11: for each PATH in resultPath 12: TGF SM ← TGF SM ∪ (σ(env),PATH,σ(PATH)); 13: end for 14: end if 15: end while

Figure 5: Unfolding Methods • sGF SM0 ∈ SGF SM is an initial state. • ΣGF SM =< E1 ; E2 ; · · · >, Ei ∈ E M is a set of labels, which consists of a message sequence. • TGF SM ⊂ SGF SM × ΣGF SM × SGF SM is a finite set of transitions.

Algorithm 2 (GFSM Construction Algorithm). 1: Stack = SGF SM = TGF SM = ∅; 2: find V in U BA; 3: input initial value for V ; 4: sGF SM0 = σ(V ); 5: push(Stack, sGF SM0 ); 6: while (Stack is not empty) 7: env = pop(Stack); 8: if (env 6∈ SGF SM ) 9: SGF SM ← SGF SM ∪ σ(env); 10: resultPath = generatePath(qU0 , σ(env));

Construction of a GFSM, shown in Algorithm 2, is a straightforward process of traversing all possible paths in the UBA using the values of the state variables using the known and fixed initial state of the system. First, states and transitions are initialized as the empty sets (line 1), and the set of system variables are identified (line 2). In our example, there is only one variable, ‘n’, whose initial value is assumed to be 1. The initial state is defined and pushed to the stack (lines 4 and 5). As long as all possible paths of the UBA have not been previously analyzed (lines 6 through 8), all feasible event sequences starting from the start state of the UBA to the final state of the UBA are identified (lines 10 through 12). When traversing the paths in the UBA, if the values of the system variables are changed, new states are created and recorded to indicate that the same UBA must be analyzed again at a later time using the new values(line 9). The valuation function σ is used to get the current values for all state variables.

For example, when traversing the UBA shown in Figure 6 with the initial value ‘n=1’, there are two feasible event sequences and . Therefore, two transitions are created in the resulting GFSM. (See Figure 7). It should be noted that  transitions introduced while constructing the UBA are ignored since they were artificially introduced as connectors. Furthermore, the path from the state ‘M.R2 [0,0]’ to ‘M.R2 [1,1]’ and all the subsequence paths are ignored when initially traversing the UBA because the activation condition ‘when n=2’ is false. However, the path from ‘M.R1 [2,2]’ to ‘M.R1 [3,3]’ indicates that the state variable ‘n’ is assigned a different value. Therefore, another state, where the value of ‘n’ is ‘2’, is created, and all possible paths in the UBA must be analyzed again with respect to the new value. It is during the latter phase of the construction where the feasible event sequences and are identified and added to the GFSM as transitions.

n=1

n=2

Figure 7: Final GFSM for MSC M Once a GFSM is constructed, test cases can be automatically generated based on the either state or transition tour coverage [8]. The former requires that each state in the GFSM is visited at least once. Likewise, the latter criteria is satisfied when each transition is visited at least once. Test cases are generated as the ordered sequence of message exchanges that must take place, and test cases are obtained by searching the GFSM in the depth-first manner.

Figure 8: MSC structure for HTML Applications

In our example, because the five state variables have two possible values and the other has four possible values, the GFSM would have 25 ∗ 4 = 128 states. If we were to assume that any of six input event may occur in all possible states, the GFSM would contain 128 ∗ 6 = 768 transitions. In our example, however, our algorithm constructed a GFSM (Figure 9) which contains 8 states and 22 transitions, thereby accomplishing 94% and 97% reduction on the number of states and transitions, respectively. However, it should be emphasized again that the degree of reduction on the size of the GFSM cannot be generalized and that our case study should be considered only as an example. s0

t2

t0 s1

t2 t5

4.

CASE STUDY

We applied the proposed approach to partially specify the required behavior of embedded software running on a digital TV (DTV) developed by Samsung Electronics (SEC). It implements the DASE (Digital television Application Software Environment) standards [9, 10], defined by the ATSC (Advanced Television Systems Committee). The DASE includes software modules that allow decoding and execution of application programs that deliver interactive and data broadcast services. DTV software consists of Java modules and native applications written in C. The former provides DASE API (Application Programming Interface), and the latter provides the vendor specific functionality such as Web browser and e-mail, etc. It is quite complex in that it has 17 tasks and threads and that there are more than 800,000 lines of code. We applied the proposed method to a part of DTV software, where four of 25 remote control unit input events and one of 42 stream data inputs were covered. The partial specification used in this case study consists of 18 bMSCs (Figure 8), which include five native tasks, seven Java threads, and six state variables.

s6 t8

t1 t6

t8

t3

t7

t4

s7

t2

t4

t8

t4 s2

t2 t0 s3

t2 t5 s4 t6

t7 s5

t2

Figure 9: Resulting GFSM for HTML Applications When the state coverage criteria was used, one test case was

sufficient to satisfy the criteria. As for the transition coverage criteria, seven test cases were generated. For example, the following test case satisfies the state coverage criteria. Actually, this sequence means the following sequence of the external input events: ‘DST ARRIVED’, ‘TV VIDEO’, ‘EXIT’, ‘CH UP’, ‘DST ARRIVED’, ‘TV VIDEO’, ‘EXIT’, and ‘CH DOWN’.

since all possible paths of the UBA must be traversed many times. In the extended application, however, test case generation based on the transition coverage criteria took about 10 minutes on a PC equipped with 650MHz Pentium III processor and 128Mb main memory running Windows/NT operating system.

5. s0 -(t0)-> s1 -(t5)-> s6 -(t6)-> s7 -(t8)-> s2 -(t0)-> s3 -(t5)-> s4 -(t6)-> s5 -(t4)-> s0

In our case study, the test sequence generated by state coverage criteria did not uncover flaws in the DTV software design. However, the test sequence based on the transition coverage criteria detected a defect that was previously unknown. It had to with a deadlock situation which may occur when two consecutive requests to change TV channels are received while the first request is still being processed. An automated integration testing environment we implemented is organized as shown in Figure 10. The MSC graphical editor enables a user to enter or edit scenario specifications, and the algorithm to generate UBA and constructing a GFSM is built-in. The MSC graphical editor and test sequence generator are written in Java to make software easily portable. Appropriate test scripts are generated, in either Java or C, although the driver itself and message monitoring software are manually developed.

CONCLUSION

This paper demonstrated that Message Sequence Charts (MSCs) formalism is useful when formally describing reactive behavior for large and complex embedded software, that MSCs can be algorithmically translated to a global finite state machine (GFSM), and that test cases can be automatically generated from a GFSM according to the state or transition coverage criteria. State variables, used to specify various activation conditions of basic MSCs (bMSCs), were used to limit the number of states and transitions included in the GFSM. We applied the proposed approach to specify a substantial portion, nearly 20% of functionalities, of complete requirements for an embedded software running on a digital TV. The case study convincingly demonstrated that the proposed approach is scalable to other industrial systems. The proposed technique can be further extended. There are constructs defined in the MSC 2000 standard but not yet supported in the toolset. The ‘Par Inline’ (parallel) construct is an example. Synchrony hypothesis is a reasonable assumption when testing embedded software whose inputs come from a single device, and when analyzing behavior of “relatively slow and less-time-critical” household applications such as digital TV software. However, if system must process inputs arriving from multiple and inherently concurrent devices, MSCs must be specified using ‘Par Inline’ and interpreted using the interleaving semantics for the concurrent inputs. It would be essential when analyzing embedded and safety-critical software requirements controlling aircrafts or factory plants. Size of resulting GFSM would definitely grow, and further reduction techniques to control the degree of state explosion problem are needed.

6.

REFERENCES

[1] David Harel. Statecharts: A Visual Formalism for Complex Systems. Sciences of Computer Programming, 8:231–274, 1987.

Figure 10: An Automated Integration Testing Environment Although details are omitted, we have applied the proposed approach to a larger subsystem of DTV software which consists of 56 bMSCs, 10 remote control unit input events, seven stream data inputs, and nine state variables. A GFSM constructed in a brute-force manner would have 4,608 states and 78,336 transitions, respectively. When the GFSM is developed as explained in this paper, only 248 states and 1952 transitions were created, thereby achieving the similar degree of size reduction. There were 17 and 875 test cases needed to satisfy the state and transition tour coverage criteria, respectively. The process of constructing the GFSM and generating test cases can be quite computation-intensive

[2] Recommendation Z.100. Specification and Description Language (SDL’2000). Technical report, ITU-T, Geneva, 2000. [3] T. Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77:541–580, 1989. [4] Recommendation Z.120. Message Sequence Chart (MSC’2000). Technical report, ITU-T, Geneva, 2000. [5] J. Grabowski. SDL and MSC Based Test Case Generation - An Overall View of the SAMSTAG Method. Technical report, University of Berne, IAM-94-0005, 1994. [6] I.S. Chung, H.S. Kim, H.S. Bae, and B.S. Lee. Testing of Concurrent Programs based on Message Sequence

Charts. In International Symposium on Parallel and Distributed Software Engineering (PDSE’99), 1999. [7] R. Alur and M. Yannakakis. Model Checking of Message Sequence Charts. In Proceedings of the Tenth International Conference on Concurrency Theory, pages 114–129, 1999. [8] C. Bourhfir, R. Dssouli, and E.M. Aboulhamid. Automatic Test Generation for EFSM-based Systems. Technical report, University of Montreal, TR-1043, 1996. [9] ATSC T3/S13 Doc. 010. Data Broadcast Specification. Technical report, ATSC, 1999. [10] ATSC Doc. A/65. Program and System Information Protocol for Terrestrial Broadcast and Cable. Technical report, ATSC, 1997.