Advanced Orbiting Systems Data Generator/Simulator: A Functional Description of the Software (Version 3)

The Advanced Orbiting System (AOS) Data Generator/Simulator is a software implementation of the transmitter (data generation) section of the CCSDS Recommendation 701.0-B-2 for Advanced Orbiting Systems: Networks and Data Links. An object-oriented approach to the simulation of a complex, high-performance communication protocol, it makes full use of the concepts of data-encapsulation and inheritance to ease implementation. The backbone of the software is a general-purpose packet description and generation module that may be used as part of any packet- based simulation software. The user-interface to the program is in the form of a command-language, designed to ease the process of generation of large, multiple data-streams. The output of the program may be configured for interpretation by a graphical user interface (for visual inspection of the data), or as a bit-stream suitable for further processing. This paper consists of three sections. The first two sections provide a brief, yet comprehensive description of the above CCSDS Recommendation. The various kinds and qualities of user-services, data units involved, and data-paths defined by the protocol are discussed. The different qualities of service (in terms or data reliability) available to the user (and the error-control schemes used to provide them) are also discussed. The last section describes the structure and user-interfaces of the AOS Data Generator/Simulator

Advanced Orbiting Systems Data Generator/Simulator: A Functional Description of the Software (Version 3)

The Advanced Orbiting System (AOS) Data Generator/Simulator is a software implementation of the transmitter (data generation) section of the CCSDS Recommendation 701.0-B-2 for Advanced Orbiting Systems: Networks and Data Links. An object-oriented approach to the simulation of a complex, high-performance communication protocol, it makes full use of the concepts of data-encapsulation and inheritance to ease implementation. The backbone of the software is a general-purpose packet description and generation module that may be used as part of any packet- based simulation software. The user-interface to the program is in the form of a command-language, designed to ease the process of generation of large, multiple data-streams. The output of the program may be configured for interpretation by a graphical user interface (for visual inspection of the data), or as a bit-stream suitable for further processing. This paper consists of three sections. The first two sections provide a brief, yet comprehensive description of the above CCSDS Recommendation. The various kinds and qualities of user-services, data units involved, and data-paths defined by the protocol are discussed. The different qualities of service (in terms or data reliability) available to the user (and the error-control schemes used to provide them) are also discussed. The last section describes the structure and user-interfaces of the AOS Data Generator/Simulator

Modeling and Testing Implementations of Protocols with Complex Messages

This paper presents a new language called APSL for formally describing protocols to facilitate automated testing. Many real world communication protocols exchange messages whose structures are not trivial, e.g. they may consist of multiple and nested fields, some could be optional, and some may have values that depend on other fields. To properly test implementations of such a protocol, it is not sufficient to only explore different orders of sending and receiving messages. We also need to investigate if the implementation indeed produces correctly formatted messages, and if it responds correctly when it receives different variations of every message type. APSL's main contribution is its sublanguage that is expressive enough to describe complex message formats, both text-based and binary. As an example, this paper also presents a case study where APSL is used to model and test a subset of Courier IMAP email server

Formal Verification of Security Protocol Implementations: A Survey

Automated formal verification of security protocols has been mostly focused on analyzing high-level abstract models which, however, are significantly different from real protocol implementations written in programming languages. Recently, some researchers have started investigating techniques that bring automated formal proofs closer to real implementations. This paper surveys these attempts, focusing on approaches that target the application code that implements protocol logic, rather than the libraries that implement cryptography. According to these approaches, libraries are assumed to correctly implement some models. The aim is to derive formal proofs that, under this assumption, give assurance about the application code that implements the protocol logic. The two main approaches of model extraction and code generation are presented, along with the main techniques adopted for each approac

Applying inspection to object-oriented software

The benefits of the object-oriented paradigmare widely cited. At the same time, inspection is deemed to be the most cost-effective means of detecting defects in software products. Why then, is there no published experience, let alone quantitative data, on the application of inspection to object-oriented systems? We describe the facilities of the object-oriented paradigm and the issues that these raise when inspecting object-oriented code. Several problems are caused by the disparity between the static code structure and its dynamic runtime behaviour. The large number of small methods in object-oriented systems can also cause problems. We then go on to describe three areas which may help mitigate problems found. Firstly, the use of various programming methods may assist in making object-oriented code easier to inspect. Secondly, improved program documentation can help the inspector understand the code which is under inspection. Finally, tool support can help the inspector to analyse the dynamic behaviour of the code. We conclude that while both the object-oriented paradigm and inspection provide excellent benefits on their own, combining the two may be a difficult exercise, requiring extensive support if it is to be successful