Java has become the preferred programming language in the traditional information-technology domain. That's because it offers improved developer productivity, greater software reuse, lower software-maintenance costs, more flexible and general software architectures, and higher software reliability.
Now, various approaches to using Java in lower-level, hard, real-time software realms have been proposed. But when Java technologies are applied to very low-level software, such as digital audio-signal processing, certain approaches deliver more of the traditional Java benefits than others.
One such approach is based on a proposed specification for a resourceconstrained and safety-critical Java definition. The driving objective in designing this approach has been the maintenance of Java's portability, maintainability, and scalability benefits. The information flow within the system includes two computers cooperating to facilitate exchanging audio information via network communication channels (Fig. 1).
Audio signals collected at one node are transmitted to the other node and output to the speakers on the remote computer. Audio signals collected at the second node are output on the speakers of the first. Conceptually, the information flow is structured as two independent streams of digital audio data.
This simple audio-processing application can be implemented as a PERC Pico application. The software, currently under development, represents the first implementation of the proposed Real-Time Specification for Java (RTSJ) profile for safetycritical and resource-constrained applications. "Hard real-time profile" refers to this environment.
MAINTENANCE AND SCALABILITY REQUIREMENTS Moore's Law helps explain the rapid growth in the size and complexity of typical embedded applications. Competitive pressures encourage software to expand to fill the capacity of ever-more-capable hardware. Studies of certain consumer electronic devices reveal that the amount of code in new product releases closely tracks Moore's Law, roughly doubling in size every 18 to 36 months.
Twenty years ago, it was common for all software in each new embedded device to be written by one or two engineers in less than a year's calendar time. Modern embedded software development is very different. Given that each new product revision incorporates hundreds of thousands, if not millions, of lines of additional code, the embedded software developer's responsibility is now shifting more toward the challenge of integrating many independently developed software components.
This simple digital audio example represents a prototypical low-level embedded software "product." For most products, the cost of developing the original software is small compared to the cost of maintaining the software throughout the product life cycle. Consider how this application would likely evolve during the product's lifetime:
The software would need to be ported to different operating systems and different processing platforms. This will change its CPU time and memory requirements.
The software would be integrated with different mixes of complementary functionality. Perhaps the next-generation product would include video signals, too. Maybe it would support the sharing of digital whiteboards to facilitate remote conferencing or possibly become integrated with e-mail and calendar software. Or, some uses may add a recording facility to capture a session to disk.
The two-node network topology may need to be generalized to support the conferencing of arbitrarily large groups of participants.
The interface to analog-to-digital converters (ADCs) and digital signal processing (DSP) may evolve. In some configurations, an operating system provides this service. In others, this application might include the devicedriver interface to the audio subsystem hardware and DMA memory devices. The audio hardware itself is likely to evolve, requiring the software device drivers to evolve.
The network communication protocols may need to change. In some circumstances, the software will rely on underlying operating-system services to interface to the network. Even the interface to operating-system network services is likely to change as various network communication protocols evolve, yielding new quality-of-service parameters and higher bandwidths. In other cases, this application will need to include the low-level device drivers for the hardware interface and may need to implement the communication protocol stacks. The same fundamental communication capabilities might be implemented on low-cost dedicated serial channels, coax and twisted-pair data links with carrier-sense multipleaccess/collision detection (CSMA/CD) technology, wireless, fiber-optic, and other media that's still to be invented. The communication libraries may incorporate compression, encryption, error detection and correction, and sliding window protocols.
This list identifies some of the many ways in which this software would likely evolve if it were put into commercial service. The list isn't intended to be exhaustive, but rather to illustrate the benefits of retaining the design advantages of Java, even for resource-constrained and hard real-time applications.
Reprints
