Design for testability of protocols based on formal specifications [chapter]

Myungchul Kim, Samuel T. Chanson, Sangjo Yoo
<span title="">1996</span> <i title="Springer US"> Protocol Test Systems VIII </i> &nbsp;
In this paper, we propose a generic scheme which instruments a formal protocol specification automatically to enhance the testability of the implementation. This approach is a special case of design for testability. It is cost-effective considering the entire cycle of protocol development. The advantage of automatic instrumentation is that the user need not pay special attention to testing problems in the design phase. Unlike most other techniques, our scheme also works with existing protocol
more &raquo; ... ecifications since it does not affect the original design. Our models address the problems of controllability and observability, and can handle both sequential and concurrent formal protocol specifications. Keywords Design for testability, formal specifications, protocols A. Cavalli et al. (eds.), Protocol Test Systems VIII © Springer Science+Business Media Dordrecht 1996 Design for testability of protocols based on formal specifications 253 on hardware products. This paper addresses the design for testability of communication protocols based on formal specifications. Design for testability on hardware, especially chip testing, is quite mature [Fujiw 85]. In fact, some techniques have been standardized. Chips that are built following the standards can be tested more easily, precisely and in a cost-effective manner using standard techniques through Test Access Ports [Parke 89]. The approach can be classified as gray-box testing, which is in between white-box and black-box testing, as it allows partial access in a controlled fashion to the internals of the system. The ultimate objectives of both hardware and software testability are similar: avoid or minimize the state space explosion problem in order to reduce the time and cost of testing. However, there are major differences between hardware and software with respect to the testing process [Hoffm 89]. The differences are mainly due to the fact that in hardware testing, we would like to determine whether an implementation (such as a chip) is an accurate copy of the circuit design since the correctness of the circuit design has been established in an earlier verification process. This is because implementations from the proven valid design may still contain serious errors introduced in the manufacturing process. On the other hand, for software, once an implementation is proven correct by testing, copies of the same implementation are always correct. In addition, hardware consisting of distributed circuits or boards often has a single physical global clock which is difficult to provide for software running in a distributed system. Communication protocols are inherently distributed and concurrent. Understanding and analyzing concurrent programs (or specifications) are much harder than those for sequential ones because the execution order of the sequential programs is fixed (or totally ordered) for a given set ~f inputs. Since Lamport's pioneering work [Lampo 78], there has been considerable research on the study of concurrency, logical clocks and global states in distributed systems. The logical clock [Matte 89, Fidge 91] is a common technique used to determine whether or not two events are concurrent. The International Organization for Standardization (ISO) and the International Telecommunication Union -Telecommunication (ITU-T) have developed formal description techniques (FDTs), viz., Estelle, LOTOS, and SDL [ISOb, ISOc, ITU], for specification of communication protocols and services in order to avoid the ambiguity of standard documents written in English. The FDTs can be used in the design phase for providing precise description of the products and for rapid prototyping. In this paper, we assume that the implementations are done according to the design described by an FDT, including the modular structure. In the case of automatic implementation of a protocol from a formal specification, the assumption is usually valid. Even when manually implementing a protocol from a design described by an FDT, the implementation process is easier and more straightforward if the modular structure of the formal specification is followed. The main contributions of this paper are: • Automatic instrumentation of formal specifications with respect to design for testability, • Provision of a practical view of controllability and observability of an implementation under test (IUT) following a formal specification, • Ability to handle both sequential and concurrent specifications, and • Provision of a mechanism for error location.
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1007/978-0-387-34988-6_16">doi:10.1007/978-0-387-34988-6_16</a> <a target="_blank" rel="external noopener" href="https://fatcat.wiki/release/a5vvyvabszak7ah4bzmdxuzf64">fatcat:a5vvyvabszak7ah4bzmdxuzf64</a> </span>
<a target="_blank" rel="noopener" href="https://web.archive.org/web/20180726223950/https://link.springer.com/content/pdf/10.1007%2F978-0-387-34988-6_16.pdf" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="https://blobs.fatcat.wiki/thumbnail/pdf/e1/a5/e1a539b4c250402369d133fd6cfa662838f443ea.180px.jpg" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1007/978-0-387-34988-6_16"> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> springer.com </button> </a>