As a major developer and proponent of Bluetooth and as a member of the Bluetooth Special Interest Group (SIG), Ericsson (Stockholm, Sweden) had a significant investment in the standard and needed to convert that investment into working technology to maintain its leadership in wireless systems. The Ericsson development teams needed a tool and a methodology which worked well for the fast-paced project and which allowed the development of application code with a minimum of coding errors and mistakes. The tool had to bypass traditional manual coding and avoid the problems that can occur with tools not capable of test simulation.
To meet these needs, Ericsson opted for a formal, graphical Specification and Description Language (SDL) design tool. As an object-oriented language, SDL is suitable for event-driven real-time and distributed systems and is traditionally used in the telecommunications industry and in safety-critical applications. With a high level of abstraction in its graphical notation, SDL makes it easy to represent both conceptual designs and their underlying implementations. SDL's formalism also facilitates the automatic generation of executable code.
SDL technology fits the nature of Bluetooth applications because it enables high-level compilation, simulation and testing. These features let Ericsson avoid the pitfalls of traditional high-level languages yet benefit from the timesaving associated with them, when developing code for small, deeply embedded systems.
The time-sensitive nature of the prototype required tool-supported code compiled in standard programming languages such as C. For design teams trying to avoid manual coding, SDL can be compiled into executable C code. In Ericsson's case, the Telelogic Tau tool produced the generated code, optimized for size and quality, that made up 40 percent of the software in the prototype. Many members of the software engineering community continually assert that the crucial strengths of formal methods and languages like SDL are the quality and compactness of generated code.
Another challenge was to clearly document the Bluetooth prototype, since ambiguous code and diagrams can elongate the adoption curve for a standard. SDL is known for its rich grammar for describing data, structure and system behavior, so the graphical specification language does not inhibit Bluetooth device developers, who have to rely on good documentation for building future applications based upon the same code.
For standardized products based on the Bluetooth specification and intended for use worldwide, diagrams must be comprehensible. Ericsson's use of SDL's documentation strengths, for example, will allow developers to use SDL documentation directly as the application's high-level documentation. SDL generates documentation content that is clear and easily understood, even by nontechnicians. To meet Bluetooth qualifications, the documentation set must also be clear and easy to read in government regulations and other, related certifications confirming product security, reliability and guaranteed compliance.
Since there seems to be an industry shift away from code-intensive basic languages, object-oriented languages like SDL offer engineers more time for creativity because they're spending less time debugging. Other benefits include superior control over the end result, easier maintenance and better usability and reusability, all of which lead to improved productivity.
Interoperability is vital to Bluetooth's success, both at the basic software/hardware level and for development and testing. From the beginning, Ericsson's team wanted to simulate how different modules of the prototype interacted. They used the SDL tool to test and find errors at a much earlier stage of the software portion for Bluetooth protocol-stack development. Overall, the process turned out to be both faster and of higher quality than is usually found with traditional programming methods.
At the most basic level of the Ericsson Bluetooth core is the protocol stack that serves as a link and physical layer. Although this basic level doesn't ensure interoperability for a Bluetooth application's end user, all devices must still be compliant at this level. Included in the basic level are processing modules for audio; the link manager, which handles setup, link control and packet transfer; the baseband; the radio; and the logical link control and adaptation protocol (L2CAP).
Following the basic level is an adapted level that must interoperate with the other protocols. The adapted level includes modules for control, RF communication, a human interface device and TCP/IP, all requiring compliance with at least one of the adapted-level prototypes, such as an Internet browser, a file transfer, a mouse, a joystick and bar-code readers.
To complement applications requiring multitasking events, SDL allows the simplification of software design for each task. This in turn lets the designer describe the application at its different levels, which are system, block, process and procedure. Further specifications are described according to structure, communication, data and reuse.
The communication mechanism is divided into two basic types, asynchronous and synchronous, and they enable information interchange for SDL multiprocessing events. SDL is designed to prevent developers from having to postpone debug to the implementation stage of product development. By working at a higher level of abstraction, the SDL system could execute during the early stage of development, prior to the availability of target hardware. The language's early validation properties improve quality while substantially reducing development costs and time-to-market. Overall man-hours decrease when problems are corrected as soon as possible without time lost searching for errors in completed prototypes. For example, the language permitted Ericsson's designers to check the robustness of the Bluetooth core against unexpected "what if" situations, helping to ensure high-quality designs.
Beyond code generation, SDL's use as a simulation tool improves system design by tackling design challenges associated with robustness. Using SDL to efficiently characterize complex Bluetooth systems, such as those involving mixed voice and data, could reduce errors early in the development process. Such errors could lead to problems with software upgrades, difficulty in coding speech, integration problems or breaks in the connection procedure.
In all projects, testing is as important to the communication and real-time development process as modeling. All Bluetooth devices must meet different testing requirements and specifications according to the particular application, i.e., audio or data communications. The qualification process ensures interoperability among multiple Bluetooth-compatible devices.
As a system-level, analyzable design language, SDL also allows for automatic test-case generation links to tree and tabular combined notation (TTCN). Some SDL tool sets, such as the Telelogic Tau SDL Suite, also include a combined SDL-TTCN simulator that allows TTCN test cases to run in the host environment. Many potential problems can be found there prior to testing in the real target environment.
The TTCN methodology for conformance testing of protocol implementation is required for Bluetooth. Test cases must be at an abstract level with a formal, high-level language in a system-independent environment. During the test phase, SDL tools can be used to reduce routine work when creating test suites by facilitating the automatic creation of test suite skeletons. For this reason, SDL-based tools output traditional high-level language code to simulate designs, as well as support functional and conformance tests.
See related chart