|
5. Software Quality of Embedded SystemsOver the past 5 years, embedded systems technology has advanced at a rapid pace. Today, very fast processors are available, especially in the digital signal processing (DSP) market. It has only been over the last 2 years that software development tools have been available to fully bring out the benefits of these new chips. In this section, I will be looking at some of these tools and how they attempt to improve the quality of software developed for an embedded task. 5.1. Quality issuesThe embedded software development process has traditionally been significantly different to that of PC development. Assembler programming was used instead of a higher level language so that efficiency of the code could be kept as high a possible. This approach can lead to code being hard to understand, and possibly being error prone. Whilst a large amount of developers have embraced higher level languages and paradigms such as object orientation and C++, there is still a need, particularly at the lower cost end of the market, to optimise code by using assembler. Because the speed and memory of embedded systems is increasing, the functionality is also increasing. This means a dramatic hike in the size of code. With traditional tools only good for small sizes, a problem that has arisen is the ability to manage large projects. Code Composer Studio from Texas Instruments has gone a long way in satisfying this need. Another issue specific to embedded programming is the high learning curve associated with it. This can be attributed to the hardware specific nature of the software development process. A new developer needs to have adequate support in place if they are to succeed in producing quality code. 5.2 Pr2imer methodKaikkonen et al. (1998) carried out a software development process improvement at Nokia Mobile Phones. Their paper describes this process and the results obtained from the improvement process. As an integral part of this process, they utilised the Pr2imer method. This method performs four major tasks:
This is a repeating methodology, with state 4 leading back to state 1. It has obvious similarities to the Deming / Shewhart Plan Do Study Act cycle. The first stage of the method, current state analysis, was implemented by sending a questionnaire to all embedded systems designers at Nokia. Secondly, the definition of the target state was developed from the results of the questionnaire. As part of this phase, GQM (Goal/Question/Metrics) was used. Planning for development measures (stage 3) involved planning to get to the target state. Finally, the improved practices were incorporated at Nokia in initial pilot projects. If these proved successful, they were to be institutionalised in every software development process at Nokia. 5.3 GQM approachGQM (Goal/Question/Metrics) as used at Nokia is described by Kiakkonen et al. (1998, pg. 20) as “measurable goals to analyse the documentation process in order to improve it with respect to reusability, and to analyse the review process in order to improve it with respect to review effectiveness and quality”. It involves defining a set of goals that wish to be reached, then questioning how to actually get there. Metrics are then used to identify areas of improvement, and also how well improvements are performing. At Nokia, this approach was directed at two main areas, documentation and reviews of code. The results of the improvement process on documentation, was the use of one configuration management tool, instead of multiple tools. With respect to reviews, each one was formally defined to have an introduction and focus area. GQM was also introduced for the analysis of the pilot project. This process undertaken at Nokia has shown that software development process improvement for embedded systems is possible using the Pr2imer method and the GQM approach. The paper did not give any conclusions on the success of the process, as it was too early in the implementation stage. It can be postulated however, that the changes made in the pilot project will increase the quality of the produced code, because of increased reusability and improved error detection methods by focused reviews. The paper also identified a classification of DSP software quality elements (figure 4), which is useful to identify how elements will affect the quality of the system.
Figure 4. How elements of an embedded system affect the quality of that system 5.4. Texas Instruments Algorithm StandardOne way to improve the quality of a system is to make sure the components of that system follow a standard that aims to reduce errors and development time. One such standard is the Texas Instruments Algorithm Standard. The white paper released by Texas Instruments (Blonstein, 2000, pg. 1) describes the purpose of the standard being “to reduce those factors that prohibit an algorithm to be easily integrated into a system without significant reengineering by the system integrator”. Whilst the lack of reengineering results in improved productivity, it also gives the ability to use reliable existing code, instead of new code requires testing. The standard defines 25 common sense rules to follow, which can be applied regardless of the area the code is developed for. These are items like variable naming conventions and proper use of comments. Section 2.3. discusses how these can improve the quality of a system. There are, in addition, ISA (instruction set architecture) specific rules for each platform that Texas Instruments (TI) produces. Each platform operates differently; therefore these rules are designed to address these differences. For example, the way in which control registers are used between platforms differs. Rules on how these are accessed are tailor made for each platform. On top of this, there are rules governing the use of hardware components such as memory. The algorithm should give all responsibility to the operating system of the DSP for managing these components. This way, the ability to use multiple algorithms at once is simplified, with resource allocation not proving to be a problem. Two articles in Embedded Edge (October 2000 and March 2001) take a close look at the standard. Five main points were highlighted as being highly beneficial to the software development process:
These issues are all good, but it must be remembered that this standard is for TI products, and is not an industry standard. Still, many of the ideas put forward by this standard are applicable to all DSP manufacturers. One possible disadvantage of following this standard is that traditional embedded programming techniques will be abandoned, even if they are the best solution to a problem. It may not be necessary to have multiple algorithms running at once, therefore directly interfacing with the hardware might be the most efficient method. The cost of the DSP chip may need to be minimised, which leads to the usage of highly optimised assembler code rather than a high level language approach. These issues must be carefully examined to determine if it is worth the effort and time to follow the standard. 5.5. Texas Instruments Code Composer StudioAs indicated earlier, up until recently, the improvements in DSP hardware technology have not been matched by software development tools for that hardware. This changed with the release of Code Composer Studio (CCS). It fully integrates the following features into its IDE (integrated development environment):
These features bring DSP development tools to a par with PC tools. Data visualisation and tracking are the most important aspects that relate to quality. These features allow a programmer to see exactly what their algorithm is doing with the data provided. This makes the detection of errors much easier and improves the reliability of code produced.
|
