What does it take to set an "industry standard" in the world of computing? That's right, an industry standard--something that computer manufacturers are willing to bet their futures on. And we're not talking about some of the computer manufacturers some of the time, we're talking about most of the computer manufacturers most of the time. What does it take to get most of the computer manufacturers to follow you into the future in the world of computing?
If we consider computer history over the last 50 years, we find that there are really only three ways that computer "industry standards" are set.
Some readers may believe that there is more to setting an industry standard than this; that one must take into consideration issues of price, quality, functionality, marketing campaigns, etc. True, such things are important in "keeping a standard going." But there are many examples of low-price, high-quality computer technologies that offer impressive functionality--and yet they do not become "industry standards."
A wonderful example of this is Microware Systems Corp.'s OS-9 operating system. This outstanding multiuser, multitask, real-time operating system, which appeared in approximately the same time frame as the single-user, single-task MS-DOS operating system, was originally designed to run on Motorola Corp.'s 8-bit 6809 microprocessor chip! If IBM had waited a little longer and adopted Motorola's 6809 microprocessor and this operating system instead of Intel's 8088 microprocessor and MS-DOS, many of the things the TRON Project was launched to achieve would have been possible a long time ago. In Japan, two computer companies, Fujitsu Ltd. and Sharp Corp., were so impressed with OS-9, that they actually developed and marketed personal computing products that could run OS-9. However, as can be surmised from reading above, since a large number of the other Japanese computer makers didn't go along with them, their product lines were eventually discontinued.
The case of ITRON-specification real-time kernels in Japan is the complete reverse of OS-9. Everyone wanted an "industry standard" for real-time kernels for machine control, which didn't exist even in de facto form, so all the Japanese electronics makers got together and cooperated at the right time, in the right place, and in the right manner. And my what a standard they have created. There is absolutely nothing like it in the history of computing!
One of the biggest mistakes the average person makes concerning computer systems is to believe that Intel Corp. manufactures almost all the microprocessors and Microsoft Corp. creates almost all the operating systems used in the world today. In fact, Intel and Microsoft only make the leading microprocessors and operating systems used in "personal computers," which represent just a fraction of the computer systems in use. But if that's the case, then where are all the other microprocessors and operating systems? This answer is in everything else around us today. Everything--from the myriad of home appliances to a very large array of industrial equipment--includes a microprocessor and an operating system. It was for this world of machinery that the Industrial TRON specification was created.
The ITRON subproject is the genesis of the TRON Project, which is to say, all the other subprojects of the TRON Project grew out of this single subproject. How did it begin? In 1980 after 8-bit microprocessors had come into widespread use and just as 16-bit microprocessors were coming into use, the OS Subcommittee of the Microcomputer Software Applications Experts Committee at the Japan Electronic Industrial Development Association conducted a study of computer operating systems on the market to determine what type of operating system software would be best for embedded microprocessor applications in the future. This OS subcommittee, which was chaired by Dr. Ken Sakamura of the University of Tokyo, came to the following important conclusions about the operating systems and microprocessors in use at that time:
In the conclusion of its report, the subcommittee recommended the launching of the TRON Project, which led to a massive collaborative effort among Japanese and foreign electronics makers to develop the TRON total architecture, which is intended to become the ultimate version of today's widely used von Neumann architecture.
Interestingly, at the time the report was drawn up, there were real-time kernels for embedded use that had been put on the market both by microprocessor manufacturers and specialty software houses. But these implementations of real-time kernels also presented many problems, which can be summarized as follows:
In order to understand what makes for a good real-time kernel, it is necessary to have a basic understanding of what it does. A real-time kernel, which is also referred to as a "real-time executive" or a "real-time operating system," can be thought of as a stripped-down, minimal operating system that "juggles" multiple tasks at very high speed in order to respond in a timely manner to external inputs. The inputs that initiate these tasks are usually from sensors or machinery, but they could also come from a human in the form of the push of a button.
Unlike a human juggler, who juggles the same type of object in a fixed sequence, a real-time kernel juggles a group of different tasks in an order that can change according to the "priority level" set for each task. Thus when a task with a higher priority is initiated, the real-time kernel has to be able to immediately switch over to the task with the higher priority by "preempting" the task in progress. An operating system that can interrupt the processing of a task in progress and switch over to another task is called a "preemptive multitasking operating system." In this type of operating system, each task is allotted a certain amount of time for processing, and thus tasks move in and out of various "task statuses," such as "RUN," "READY," "WAIT," "SUSPEND," "DORMANT," "NON-EXISTENT." Exactly how many statuses there are and how the real-time kernel moves from one to another greatly affects functionality and processing speed.
In addition, the tasks being processed by a real-time kernel usually have to communicate with each other to synchronize their inputs and outputs. This is because, for example, the output of one task might be used as the input for another task, or one task may have to finish processing before another can begin--so there has to be a mechanism or mechanisms that allow for communication and synchronization among the various tasks that the real-time kernel processes.
Accordingly, designing a high-performance real-time kernel involves a lot of clever planning to get the best performance while achieving a highest possible degree of functionality. And in the case of the ITRON architecture, which is intended for creating kernels that can run on any manufacturer's microprocessor, whether it be 8-bit, 16-bit, or 32-bit, even cleverer planning had to be employed. So what has been done in the ITRON subproject to obtain the highest performance while maintaining the highest degree of performance?
First, in order to cover the different microprocessor types (8-bit, 16-bit, and 32-bit), and also to cover all the major application areas (loosely coupled networks, shared memory systems, etc.), a "family of ITRON specifications" was planned. These are:
- ITRON1 (primarily for 16-bit microprocessors in the mid 1980s)
- ITRON2 (for high-performance 32-bit MPUs such as the TRON VLSI CPU)
- micro-ITRON2.0 (for 8-bit single-chip microcontrollers)
- micro-ITRON3.0 (combination of ITRON2 and micro-ITRON2.0 with network support for loosely coupled networks)
- ITRON-MP (for shared memory multiprocessor systems)
- IMTRON (support for large-scale, dynamic networks such as the TRON Hypernetwork [HFDS])
In addition, these specifications are divided into "levels," i.e., required (Level R), standard (Level S), and extended (Level E), so that they can be scaled up or down to allow for the maximum number of implementations in a given application area. (Levels R, S, and E, can now be enhanced with networking functions, "N," thus becoming levels RN, SN, and EN, respectively.)
Second, for each specification, only the functions that won't lower system performance were standardized. In the TRON Project is referred to as "weak" or "loose" standardization. The purpose for this is to obtain the maximum performance from the hardware so as to achieve the fastest possible switching time between tasks. Accordingly, excessive virtualization of hardware is avoided, and there are many design matters that are decided on a processor-by-processor basis; in ITRON specifications, these implementation-dependent functions are referred as "CPU dependent" (Level C).
Third, a wide variety of functions was provided in the various ITRON specifications, but it is not "required" to employ all for them for an implementation. For example, in the case of the mechanisms for task synchronization and communication mentioned above, ITRON specifies all three major types, i.e., the event flag, the semaphore, and the mail box, but the developer is able to select just the one or ones needed for a particular implementation.
Fourth, emphasis was placed on the training of programmers. As noted above, since there was no standard, de facto or otherwise, in the area of real-time kernels, there was not even a standard way of talking about them. As matter of fact, outside of the world of ITRON, there still isn't. Experts in this field get into heated debates about what "real time" means, and even how to define a "real-time kernel." Accordingly, by standardizing the training of programmers, programmers can carry their knowledge and experience from one implementation to another and talk about system requirements in a non-polemic manner.
Fifth, a standard real-time file system was designed that can be used by all the ITRON-specification real-time kernels. This file system, which is called ITRON/FILE, is a subset of the BTRON file system, and it consists of a "flat file" (<<FI0>>) specification, a "tree structure file" (<<FI1>>) specification, and a "network file" (<<FI2>>) scheduled for development at a later date.
As was stated above, the ITRON subproject is the genesis of the TRON Project, and hence it should come as no surprise that an ITRON1-based kernel predates even the founding of the TRON Association in June 1986. The first ITRON1-specification kernel to be announced and shipped was NEC's RX116 for its V20, V30, V40 and V50 microprocessors, which came out in the Spring of 1985. This was followed by other ITRON1-specification kernels: Hitachi's HI68K for Motorola's MC68000 microprocessor series, which began shipping in August 1986; and Fujitsu's REALOS/286 for Intel's iAPX286, which the company started shipping in May 1987. And in November 1987, Mitsubishi Electric announced its ITRON/32 kernel for National Semiconductor's NS32000 series microprocessors (this was the first true 32-bit MPU to hit the market). In addition, in November 1987, Hitachi announced its HI68KA ITRON-based filing system.
Interestingly, there was so much ITRON-related research and development work going on that the ITRON Technical Committee was not established within the TRON Association until December 1987. Moreover, although everyone was developing real-time kernels based on the ITRON1 specification, it was not officially released by the TRON Association until 1987.
All of the above ITRON-based kernels were first generation kernels aimed at testing out the concepts ITRON architecture on the existing 16-bit microprocessors that predominated at the time. Once the ITRON concept was validated, the ITRON architecture bifurcated into two second generation streams: micro-ITRON2.0 for 8-bit single-chip microcontrollers (this is an area where it had previously been impossible to employ a real-time kernel due to hardware limitations), and ITRON2 for microprocessors based on the 32-bit TRON VLSI CPU architecture. Both the micro-ITRON2.0 and ITRON2 specifications were announced in 1989.
The kernels based on micro-ITRON2.0 are too numerous to list and describe in detail (please click here for the micro-ITRON2.0 kernels currently available). Needless to say, every major manufacturer of single chip 8-bit microcontrollers in Japan developed and marketed a micro-ITRON2.0-based real-time kernel to support its chips. In fact, as a result of the adoption by Japanese electronics manufacturers, the micro-ITRON specification has become the first standard operating system for single-chip microcontrollers. As for the ITRON2 specification, Fujitsu, Hitachi, and Mitsubishi, the three companies that developed the Gmicro series of 32-bit microprocessors based on the TRON VLSI CPU architecture, developed and announced the REALOS/F32, HI32-200, and MR3210 kernels, respectively.
Following the successful completion of the micro-ITRON2.0 and ITRON2 specifications 1989, the ITRON/FILE specification was published in 1992, and the micro-ITRON3.0 specification, which brings together the vast base of experience gained through multiple implementations of previous ITRON specifications and adds to it support for loosely coupled networks, was released in 1993. At present, research and development is moving ahead on the next two generations of the ITRON architecture: ITRON-MP specification, which will support systems with multiple processors; and the IMTRON specification, which will support the type of computerized living and work spaces envisioned by the TRON Project.
The main functions of the micro-ITRON3.0 specification are as follows:
- Direct manipulation and referencing of tasks
- Task synchronization function in the task itself
- Three synchronization and communication functions independent of tasks, i.e., semaphore, event flag, and mailbox functions
- Two advanced task-independent synchronization and communication functions, i.e., message buffer and rendezvous (previously supported only in ITRON2)
- Function for defining a handler for external interrupts
- Function disabling and enabling external interrupts
- Functions for software management of memory pools and memory block allocation (both fixed-size and variable-size memory pools are supported)
- Functions for system clock setting and reference
- Task delay function
- Time handler functions (cyclic start handler, alarm handler)
- Functions for setting and referencing the system environment as a whole
- Management and support functions for loosely coupled networks
The ITRON subproject is not only the subproject with the longest history in the TRON Project, it is also the subproject that has led to the greatest number of commercializations of TRON-based products. Since the complete list of ITRON-based products is too long to include here, only the "product areas" in which ITRON-specification kernels are being applied will be listed below.
- Televisions with high-level functions
- Video equipment
- Audio equipment
- Air conditioners
- Washing machines
- Microwave ovens
- Rice cookers
- Printers
- Photocopiers
- Image scanners
- Word processors
- Optical filing systems
- Multifunctional telephones
- ISDN telephones (Fig. 1)
- Facsimile machines
- Broadcast equipment
- Wireless systems
- Antenna control devices
- Satellite control systems
- Automobiles
- Vending machines
- Lighting control devices
- Electronic musical instruments (Fig. 2)
- Factory automation computers
- Industrial robots
- Measuring instruments
- Core kernel for personal digital assistants (PDAs)
- Core kernel for workstations
The ultimate goal of the TRON Project is to create the TRON Hypernetwork (also know as the Highly Functional Distributed System [HFDS]), a vast network in which literally billions of computers will be linked together either directly or indirectly. The overwhelming majority of the "computers" in the TRON Hypernetwork will be "intelligent objects," in other words, computerized devices based on the ITRON architecture. Therefore, the first step in creating the TRON Hypernetwork is drawing up the ITRON specifications that will allow for ITRON-based computer systems to communicate with each other across networks.
The first step in this direction has already been taken in the micro-ITRON3.0 specification, which has functions to support "closed networks." A closed network is one in which the interactions between the nodes (the network configuration) are preplanned by human beings. However, there is another type of network that will exist in the TRON Hypernetwork, the "open or dynamic network" in which the network configuration will be set automatically without the intervention of humans and will be constantly changing. It is for this type of network that the IMTRON specification is being drawn up. In order to realize this type of network, several technical hurdles must be overcome. For example, it is necessary to have high level protocols that will enable the various nodes to "converse" with each other. There must also be a language system for programming based on these protocols, and issues such as fault tolerance and real-time network communications must also be addressed.
In order to introduce higher performance and ensure fault-tolerant operation at individual nodes, the ITRON-MP (multiprocessor) specification for systems with multiple microprocessors and tightly coupled shared memory is being drawn up.
One of the biggest issues involving ITRON in the future is what type of interface or interfaces to give ITRON-based devices within the TRON Hypernetwork. In original TRON Project planning, the interface for the TRON Hypernetwork was to be the BTRON machine. In other words, if a person learned the BTRON interface, that person would be able to operate the functions of the TRON Hypernetwork. However, now that the component technologies that make up the TRON Hypernetwork are taking shape and are actually being applied in experimental environments such as the TRON Intelligent House, the concept of the human/machine interface within the TRON Hypernetwork also is beginning to evolve. One part of this evolution is to prepare separate interfaces for ITRON-based devices, which according to current thinking could fall into three categories: ITRON-GUI (provisional name), ITRON+BTRON HMI, and ITRON + BTRON HMI via the TRON Hypernetwork.
ITRON-GUI refers to very simple, standardized interface hardware panels that would be built into the control units of various types of equipment that are used in human living and work environments, such as video cassette recorders and photocopier machines. ITRON + BTRON HMI is a network scheme in which the BTRON-specification computer would be used as the interface for ITRON-based devices via a simple LAN using low-level protocols, such as those for today's RS-232C serial port standard. And ITRON + BTRON HMI via the TRON Hypernetwork is a network scheme in which a BTRON-specification computer would be used as the interface for ITRON-based devices via the TRON Hypernetwork using high-level protocols of the TRON Hypernetwork embodied in the TAD standard.
Interestingly, creating HMI panels on a BTRON-specification computer for ITRON-based devices is very simple using the MicroScript language developed by Personal Media Corporation. This BASIC-like language uses an interpreter that translates code to an intermediate language, which allows for code to run at high speed. In addition, it has the required mechanisms for writing multitasking programs, such as synchronization and memory sharing. It is also possible to write programs based on an event-driven programming style, and it has an HMI parts library for rapidly designing interfaces, which can be changed at will since they are completely separated from the programming code.
One of the "performance targets" of the ITRON subproject is to achieve a context switching time of "1 microsecond." In order to attain this high-speed performance research is in progress on how to realize the ITRON-specification on a VLSI chip. An ITRON-based VLSI chip would allow for high-speed operation with low power consumption and high reliability. Another possibility is fabricating an ITRON-specification operating system on the same piece of silicon as the TRON VLSI CPU, which would allow for the creation of a one-chip computer system.
Since real-time operating systems based on the ITRON specification are being developed and commercialized by various companies, another area of research is how to validate conformance to and functionality required in the ITRON specification in question. This type of research is something that is peculiar to the TRON Project, and it may not seem like a very important field of research in some circles. However, it is vitally important that those who develop and market products based on TRON specifications follow those specifications to the letter so that their products will be compatible and interoperable with other makers TRON-based products.
So where does this leave ITRON? Well, ITRON is now the standard for the Japanese electronics and automotive industries, and it is continuing to spread into other fields in Japan. Will it completely take over the market? That remains to be seen, but the chance is high that this will be the case, since the ITRON architecture is an "open architecture." Moreover, continuing research and development is pushing the envelope of what the ITRON architecture can do, making it more and more attractive to Japanese companies attempting to do new things with microprocessors.
However, the biggest question is not how far ITRON-specification operating systems will spread in Japan, but how far they will spread overseas. Since free source code for an ITRON-based operating system called ItIs (see below) is now available via the Internet, the chance is high that ITRON will attain to some extent the success that has been achieved by Linux, which is also free and available via the Internet.
In any event, the ITRON architecture exists for a particular purpose, and that purpose is to serve as the standard real-time operating system for the billions of computerized "intelligent objects" that will fill human living spaces and automated work environments in the future. As can be surmised from reading the above, the ITRON architecture is well on its way toward achieving that goal.
Basic information on the ITRON architecture can be obtained from the proceedings of the annual TRON Project symposia. These were published by Springer-Verlag from 1987 to 1990, and have been published by the IEEE Computer Society Press since 1991.
The best source for technical information on the ITRON subproject is the ITRON home page of the TRON Project Web site at the University of Tokyo, which offers an English language web page, specifications in English, plus free ITRON source code. The URL is as follows:
http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html
