T-Engine: the Open, Real-Time Embedded-Systems Platform

T-ENGINE: THE OPEN, REAL-TIME EMBEDDED-SYSTEMS PLATFORM

THE GROWING POPULARITY OF REAL-TIME EMBEDDED SYSTEMS CREATES AN

URGENT NEED FOR IMPROVED PERFORMANCE AND EXPANDED

FUNCTIONALITY. THIS OPEN ARCHITECTURE HELPS OPTIMIZE THESE SYSTEMS.

Computer system architecture has specifications. These changes underscore the conventionally been standardized, as evidenced need for a standardized system. However, by the IBM System 360 architecture for main- architects must still develop and customize frame computers, the IBM PC specifications real-time embedded systems to accommodate for desktops, and today’s so-called Wintel individual devices and their specific needs. (Windows-Intel) specifications. Standardized This hinders improvements in software pro- architectures have significantly improved the ductivity, and software makers now find it dif- reusability of both hardware and software, and ficult to meet market demands. the efficiency of system configurations. For these reasons, we recently developed a No such standardized architecture has system architecture standard for real-time arisen for real-time embedded systems. This is embedded systems called T-Engine. because conventional, real-time embedded systems use low-performance microprocessors Philosophy to keep hardware cost small, which makes it T-Engine is a standard architecture for next- necessary to optimize hardware and software generation, real-time embedded systems aimed Ken Sakamura for each application. Standardization of sys- at improving software productivity for these tem architecture only results in increased systems. An open consortium, the T-Engine Noboru Koshizuka waste in systems and the failure to satisfy econ- Forum (http://www.t-engine.org) in the omy and performance demands. TRON Project (http://www.tron.org), devel- University of Tokyo The growing application of real-time oped this architecture. Consortium members embedded systems to personal digital assis- include computer hardware and software ven- tants (PDAs), mobile computing devices, and dors, telecommunication carriers, and com- pervasive/ubiquitous computing systems has puter-using companies. T-Engine development created an urgent demand for more diverse followed a strong philosophy that recognizes software in these systems. Moreover, applica- the importance of an open standard, middle- tions increasingly rely on software that can ware distribution, a good balance between vir- handle more complex tasks such as security- tualization and adaptation, chip-free hardware related jobs, distributed processing, ciphering standardization, and security. and authentication, and multimedia processing of voice and video data. These changing Open standard requirements for the computer environment The open system is an important part of the create a disadvantage in terms of reusability, philosophy for a next-generation, real-time development cost, and time to market for con- embedded-systems architecture. An open sys- ventional systems based on custom-made tem is based on certain commonly available,

48 0272-1732/02/$17.00  2002 IEEE established specifications. Should an imple- ware—even if they come from different devel- mented system based on an open standard opers—and encourages distribution of the contain faults, any designer can develop portable software to software developers. another system compatible with the open Some projects attempt to enhance the standard and fix the problems. Thus, open reusability of software by applying object-ori- systems prevent any company or organization ented component technology (http://www. with a proprietary system from monopolizing cs.wustl.edu/~schmidt/TAO.html and http:// the particular market segment where such www.ovmj.org).2-3 This approach is useful for software with specific functions is in demand. large systems, such as for military equipment This open-system feature is significant for real- and aircraft. But it’s not suitable for small, time embedded systems, because such systems commercial, embedded systems, such as must combine various computer systems. mobile phones and office equipment (prod- In the Unix community, open systems are ucts that face severe price competition) because popular, and many software systems adopt the object-oriented approach often requires open licenses. The most well-known open-sys- substantial hardware resources. T-Engine tar- tem project is the GNU Project (http://www. gets these smaller systems. gnu.org) headed by R. Stallman. Many other The T-Engine architecture contains the successful open-system projects include Linux minimum amount of software needed to fill (http://www.linux.org), FreeBSD (http://www. the gap between different units of hardware, freebsd.org), and Apache (http://www.apache. enhancing this software’s portability and min- org). imizing its runtime overhead. To ensure this For embedded systems, on the other hand, portability, the kernel provides only a mini- a major open system project is the Real-Time mum set of well-defined application program Operating System Nucleus, or TRON.1 interfaces (APIs). Aside from the APIs, we TRON’s openness lets anyone freely use its define a set of standard software formats called software and hardware specifications, regard- T-Format, which includes format specifica- less of whether the application is commercial tions for binary code, style guidelines for or not, or the source code is open or closed. source code, and formats for rules and docu- Unlike GNU’s general public license, TRON ments. To ensure software portability, in addi- neither forces anyone to disclose changes tion to defining T-Format, we standardize the made to its original specifications nor forbids software development environment and offer anyone from mixing open with nonopen sys- a solution to architects that will reinforce their tems. Moreover, the TRON project’s specifi- education process, helping to popularize the cations for reference implementation are also use of these standards. open. In general, embedded systems do not virtualize system hardware resources because Virtualization versus adaptation of the emphasis on performance, often mak- Advances made in hardware mounting ing direct hardware access essential. Because technology have exponentially increased the of this fact, open-source code for such systems computing capability and storage capacity of could let anyone access confidential informa- embedded computers. Therefore, you no tion about the proprietary hardware used in longer have to run programs within just a few such systems. Therefore, with embedded sys- dozen kilobytes of memory on an 8-bit micro- tems, practical development would be impos- processor. Nevertheless, to save power and sible if the systems were entirely open. resources, it’s still important to make embedded systems as compact as possible and reduce Middleware distribution CPU load. It’s clear that the computer indus- To improve the productivity of real-time try will not accept a system architecture that embedded-systems development, it’s impor- requires excessive virtualization of its hard- tant to enhance software reusability. To ware resource management. Managing hard- achieve this, software developers must make ware resources in software with excessive portable software that can run on various virtualization is simply too slow and consumes hardware systems. This lets multiple software too much CPU time. For this reason, we programs run together on the same hard- defined standard specifications for the T-

NOVEMBER–DECEMBER 2002 49 T-ENGINE

Target system Development Product system Development system environment system Software layers T-builder Application software in T-Format Application layer GNU C compiler GNU Middleware layer Middleware in T-Format assembler GNU debugger Kernel layer T-Kernel front end

Unix-based OS Monitor layer T-Monitor Monitor Hardware layer

pT-Engine Debug support nT-Engine hardware µT-Engine In-circuit emulator T-Engine appliance T-Engine Functional Functional specification specification Product-based Physical physical specification specification Scale Scale

Figure 1. Model of the T-Engine architecture.

Engine architecture while carefully balancing The growing number of security incidents has virtualization and adaptation, in accordance become a concern for computer users with state-of-the-art hardware technology. (http://www.cert.org).4 Many specialists believe that one underlying cause of this problem is that Chip-free hardware standard Internet builders failed to anticipate such secu- In terms of system adaptability, it would do rity incidents.5 In tomorrow’s ubiquitous com- more harm than good to standardize CPUs, puting environment, computers will be fully considering the current state of technology, integrated to support daily activities, so we must which uses a large variety of CPUs. For the T- discard optimistic perspectives regarding com- Engine architecture, we standardize hardware puter security. In such an environment, once a at the board level and leave the CPU type cracker succeeds in intruding into your com- undefined. Consequently, many types of hard- puter through a network, boiling water could ware units with different CPUs are compati- gush from the bathtub, an electronic oven might ble with the T-Engine specification. Hence, burst into flames, or the TV could suddenly it’s necessary to recompile source code to start broadcasting a baseball game at too high a ensure software portability. Compatibility is volume.6 Therefore, in the T-Engine architec- at the source, not binary, level. ture’s basic design phase, we have incorporated a network security mechanism that does not Security require any user effort, because most users will As evidenced by the recent, wide application know little about their system’s mechanisms. of ubiquitous computing, most future real-time embedded systems will exist in a network to System model approach which all nodes connect. Compared to systems To clarify the objective of the T-Engine in which each node operates independently, specifications, we have set up the T-Engine such systems face a security problem: How do reference system model consisting of a target you protect system nodes from network attacks? system and a development environment sys-

50 IEEE MICRO tem. The target system is where the developed The software layer contains software runs. The development environment standard sets of specifications. T-Engine (75 × 120 mm) system is where developers build the software. Following these specifications In embedded systems, the target system and ensures that software is suited µT-Engine (60 × 85 mm) the development environment are usually dif- to run on hardware satisfying ferent. The layered design of these systems T-Engine’s functional specifi- defines specifications for each layer. Figure 1 cations. Unlike the hardware shows a model of this architecture. specifications, the develop- nT-Engine ment and product systems Target system’s layered architecture share the software specifica- In the T-Engine target system’s layered tions—except for a debug architecture, each set of hardware specifica- support function, which only pT-Engine tions includes the development system supports. We further divide the • functional specifications describing cir- software layer into the follow- cuit operations, and ing four layers: • physical specifications defining the sizes and positions of connectors and other • Monitor. This software components. enables basic operations on T-Engine hardware, Figure 2. T-Engine hardware sizes. The hardware layer handles system specifi- including functions that cations separately for development and prod- run application software, ucts, but the development and product load it into memory, and read from and systems share the standardized functional write to memory. This layer defines a specifications. This sharing assures that the standard specification called T-Monitor. same software works on both systems. We • Kernel. This is the real-time kernel of the strictly define functional specifications for T-Engine system architecture, as defined peripheral hardware, but, for reasons men- in the T-Kernel specifications. tioned previously, we leave them unspecified • Middleware. This layer provides services for the CPU to expedite the adaptation of T- to application software with user-defined Engine on application systems. system calls, application tasks, and Physical specifications for the development libraries offered by T-Kernel. The T-For- and product systems might not be the same. mat specification standardizes formats for For development systems, we strictly define middleware source and execution code. and standardize the board size, connector type • Application. This layer enables applications and position, electrical properties, and other based on the T-Engine architecture. As in characteristics. This enhances the reusability the middleware layer, T-Format defines of expansion boards. On the other hand, our the code formats for application software. approach permits and actually recommends installing product systems based on different Target system’s scalable architecture physical specifications, provided that the sys- We’ve developed several system architec- tems satisfy the functional specifications. For tures, each aimed at a different target system instance, when installing a target system on a size. Figure 2 shows the four architectures avail- potentially popular product, it’s better to make able now: T-Engine, micro- or µT-Engine, custom LSI chips and install lower-cost and nano- or nT-Engine, and pico- or pT-Engine. more compact hardware based on the same functional specifications as those of T-Engine. Development environment system’s layered In the case of products in smaller lots, not architecture requiring downsizing, it’s efficient to use the The hardware layer for the development development system as the product system. To environment includes several types of hard- support this, we have made the board size in T- ware—the in-circuit emulator, for example— Engine’s physical specification as compact as for hardware emulation and testing. The possible. T-Engine architecture does not specifically

NOVEMBER–DECEMBER 2002 51 T-ENGINE

define hardware specifications except for the Entity TRON (eTRON) architecture,7 sup- interface between the hardware and the tar- ported by T-Engine hardware, the operating get system, and the interface with higher-level system, and middleware. We equipped T- development environments. Engine hardware with tamper-resistant chips The software layer includes a development based on eTRON, enabling mutual authen- environment layer and an operating system or tication and encrypted communications using kernel layer. The development environment a public-key infrastructure on insecure com- software includes compilers, linkers, assem- puter networks, such as the Internet. blers, and front-end systems for cross debuggers. T-Builder is the standard development Standard hardware environment specification for these systems and The T-Engine platform is mainly suited for components. T-Builder’s specifications con- real-time embedded systems in ubiquitous form to those of GNU development systems. computing environments. In addition, these For development, a programmer could use systems are suitable for an extensive range of any operating system or kernel that T-Builder applications. To cover such a vast application (the standard development environment) can range, the four established sets of hardware run on the system. In our present reference platform specifications shown in Figure 2 han- implementation, we use a Unix-based oper- dle different sizes, power levels, and process- ating system. ing capabilities. Other system strategies T-Engine The use of commercial off-the-shelf The standard T-Engine platform is suited (COTS) products is an important strategy for for mobile information appliances such as T-Engine, saving system development costs. next-generation mobile phones and electron- The use of eTRON provides a secure com- ic-book readers. Suitable devices would have puting solution in the T-Engine architecture. a graphic display and an input device, pro- viding an advanced user interface; run on a Commercial off-the-shelf use battery; and have a wireless communication When building a real-time embedded sys- function. tem, the volume of available software and T-Engine physical specifications for this hardware resources is so large that it’s cost- platform define the board size (75 × 120 mm), effective to use these instead of building new some component positions, and the periph- ones from scratch. To keep cost low, we eral device’s interface connector sizes. In accor- employ de facto standards as much as possible dance with the philosophy of using COTS in the T-Engine system architecture. For exam- parts, we incorporate as many de facto stan- ple, we use established GNU standards in the dards as possible into the physical specifica- standard system development environment. tions. The only new specification concerns an For software and peripheral hardware, the T- expansion connector. This specification is Engine system permits the use of COTS prod- common in T-Engine and µT-Engine. We ucts. For instance, to use open-source software assign the bus signal to this expansion con- on Unix as middleware, we are considering nector to connect the expansion board to the porting Unix operating systems onto the T- system board. Under T-Engine and µT- Engine architecture as a kernel extension of T- Engine functional specifications, this con- Kernel. To effectively use software written in nector attaches to the chip bus on each CPU. Java, we also plan to incorporate a Java virtu- Consequently, different CPU architectures al machine and some adequate profiles. generate different bus signals. A physical key, or notch, on this expansion connector pro- eTRON tects against the mistaken insertion of the Ensuring the security of a T-Engine real- wrong expansion board into the wrong slot, time embedded system requires incorporat- ensuring only the connection of compatible ing a standard architecture that establishes a boards. The T-Engine Forum defines the security foundation for the network environ- physical key notch specification and assigns a ment. For this purpose, we employed the signal to the expansion connector. Moreover,

52 IEEE MICRO an eTRON chip slot provides Table 1. T-Engine hardware specification (overview). a standard to support T- Engine security processing. Device Specification Table 1 outlines the T-Engine CPU Any CPU with memory management unit specifications. RAM Any size Flash ROM Any size µT-Engine eTRON SIM interface SIM card connector; ISO-7816-compliant interface The µT-Engine is a stan- LCD interface One channel dard platform for computers Real-time clock Battery-backed-up calendar clock embedded in such units as PC card interface One type, two slot (PCMCIA release 2.1) home appliances and in mea- USB host interface One channel; USB specification rev. 1.1 compliant suring equipment. Its board Sound interface One-channel stereo headphone and microphone jacks size is 60 × 85 mm, and it Serial interface Simplified RS-232-C does not necessarily need a Bus extension 140-pin T-Engine standard connector with antierrant insertion keying memory management unit (MMU). We apply the same specifications used for T-Engine to the expan- Table 2. µT-Engine hardware specification (overview). sion connector to enable the sharing of hardware components between both engines. Device Specification Unlike T-Engine, a graphic display is not CPU Any CPU; memory management unit is optional required because µT-Engine devices would RAM Any size use a simple user interface. This platform also Flash ROM Any size provides an eTRON chip as standard. Table eTRON SIM interface SIM card connector with an ISO-7816-compliant 2 outlines µT-Engine specifications. interface Real-time clock Battery-backed-up calendar clock nT-Engine Compact flash card interface One type, two slot The nT-Engine is an inexpensive, coin-sized Secure-digital or multimedia- hardware platform intended for such nodes as card interface One slot lighting fixtures, sensors, and window con- Serial interface Simplified RS-232-C trollers. It consists of a processor core, network Bus extension 140-pin T-Engine standard connector with interface, and peripheral functions. A hardware antierrant insertion keying library integrates the necessary peripheral functions. This platform serves as a processor core, combining functions to create a target system. T-Kernel design concept T-Kernel is the standard real-time operat- pT-Engine ing system for (standard) T-Engine and µT- The pT-Engine is a chip-shaped platform Engine. Neither nT-Engine nor pT-Engine with a sensor function and a wireless or opti- use T-Kernel or its equivalents because both cal communication function. Only several platforms have extremely small amounts of millimeters in size, pT-Engine fits into a large computing resources. variety of unpowered objects, including cloth- For nearly 20 years, the TRON Project has ing, desks, chairs, paintings (hanging on focused on constructing a ubiquitous com- walls), dishes, and drug bottles. Rather than puting environment. During the course of the just a simple radio frequency identification project, we published Industrial TRON (RFID) device, pT-Engine is also a computer (ITRON), which are open specifications for a with processing capability. For example, this real-time kernel in computing nodes and the chip could attach to a wine bottle in transit to ancestor of T-Kernel. The ITRON-based, monitor and record temperature and vibra- real-time embedded kernel has a large number tion data for quality assurance. To run on of applications, including mobile phones, unpowered objects, the chip might use elec- engine control systems in automobiles, digi- tromagnetic energy from a communication tal cameras, and fax machines. It has become medium or power generated by microelectro- a platform for a wide range of middleware, mechanical systems using micropulsation. device drivers, and applications. These appli-

NOVEMBER–DECEMBER 2002 53 T-ENGINE

Application Application 1 2 software

Subsystem 1 2 Device 2 Middleware driver 1

T-Kernel/ T-Kernel/OS T-Kernel/ T-Kernel Debugger Support System Manager

T-Monitor T-Monitor

Figure 3. T-Engine runtime software architecture.

cations can run on the standard T-Engine and system permits kernel extension and the con- µT-Engine with slight modiﬁcations. struction of both light and advanced systems As described previously, the T-Engine Pro- on the same kernel. T-Kernel Extension is the ject seeks to apply a real-time embedded kernel extended portion of an operating system cre- to a large variety of systems. Even for just T- ated with this subsystem. The T-Kernel Engine and µT-Engine, applications range Extension provides from a small, single-purpose embedded unit to a large-scale server system. T-Kernel is so scal- • a virtual memory using an MMU; able that it can cover—with a single kernel • a process management function to mod- architecture—a wide array of systems. These ularize programs such as those for systems range from lightweight, compact real- resource management; time systems that operate under severe cost and • an event management function to resource restrictions (light systems) to advanced process information entered using a key- server-oriented systems equipped with a virtu- board and mouse, and to monitor device al memory unit (advanced systems). conditions; and The T-Kernel design concept provides two • a ﬁle management function. advantages: It helps individual software applications implement common functions for the T-Kernel alone permits the construction of increasingly popular large server systems and lightweight and compact conventional real- small embedded systems. It can also manage time systems, whereas T-Kernel and T-Kernel small embedded systems in their initial devel- Extension combined can realize advanced sys- opment phase, before they evolve into larger tems. T-Kernel also has a function not pro- systems. vided in ordinary real-time kernels: the Mobile phones in Japan offer a good exam- dynamic management of kernel objects such ple of these two advantages. Initially, mobile as tasks and semaphores to facilitate the addi- phones only had a phone function, but dur- tion of miscellaneous middleware and device ing the past couple of years, they have begun drivers. offering many other functions such as Web browsers, games, and personal information T-Kernel components management. The T-Kernel design concept is T-Kernel consists of three function classes, useful in dealing with such rapid changes in shown in Figure 3. The first class includes scale. For this reason, we designed a real-time basic real-time kernel functions, such as task kernel based on unified, scalable specifica- management, semaphores, and event flags. tions, instead of designing different operating The second class is a subsystem management systems for light and advanced systems. function to expand the kernel, and a set of To give T-Kernel high scalability, we intro- functions to enhance the middleware porta- duced the concept of a subsystem. This sub- bility. The third class is a set of functions to

54 IEEE MICRO support the task-level debugger. Application/subsystem/device driver/others The portion of T-Kernel that offers the ﬁrst function class—basic real-time kernel func- Extended supervisor calls tions—is called T-Kernel/OS. The second Extended supervisor function class to enhance middleware porta- Resource bility includes functions for device manage- Subsystem management 2 ment to standardize the means of accessing block 1 devices, interrupt management to standard- startup cleanup break event ize the interface with the interrupt handler, Events and power management. We call this portion of the kernel the T-Kernel/System Manager T-Kernel (SM). The functions to support developing debuggers include one to check the status of Figure 4. T-Kernel subsystem. such objects as tasks, semaphores, and queues. The functions also check and set internal information in the task control block, mak- T-Kernel/SM and device management ing it possible to read information like the reg- The T-Kernel/SM extended functions set ister value of each task. This portion is called manages the overall system. The set includes the T-Kernel/Debugger Support (DS). the following functions:

T-Kernel middleware portability • System configuration information man- To accelerate the distribution of middleware agement manages and maintains system that runs on T-Engine, T-Kernel has a frame- configuration information, for example, work to modularize middleware and a set of the maximum number of tasks. functions to support a dynamic software con- • System memory management controls all figuration mechanism. The middleware mod- system memory units dynamically allo- ularization framework includes subsystem cated by T-Kernel. functions contained in T-Kernel/OS and a • Device management controls the interface device management function included in T- with device drivers. Kernel/SM. We have introduced two functions • Address space management checks mem- to support dynamic software configurations: ory address space and access rights, and one to automatically allocate unused identifiers executes address transformation. to kernel objects at their creation and one to • Interrupt management enables basic oper- implement multiple logical memory spaces. To ations related to interrupt management. create multiple logical memory spaces, we use • I/O port access support provides basic T-Kernel/SM functions that manage system access to I/O ports. memory and address space; the MMU on the • Power management enables operations CPU supports these functions. As with typical related to power management. This func- large-scale operating systems for PCs and tion is especially important in a ubiqui- servers, the multiple logical memory spaces let tous computing environment, which us load and run new applications and middle- frequently suffers from inadequate power. ware in an independent logical memory space. Middleware and software development T-Kernel subsystem management The T-Engine Project is constructing a stan- T-Kernel is a real-time kernel based on such dard development environment (T-Builder), a functions as task scheduling, synchronization, standard format of distributed software (T-For- and communication. It neither includes file mat), a basic collection of standard library mid- management nor GUI-related or communi- dleware (T-Collection) that runs on T-Kernel, cation functions. You can implement these and a framework for distributing and selling functions by adding a subsystem to T-Kernel software (T-Dist) that runs on T-Engine. using subsystem management functions in the kernel. Figure 4 shows the typical structure of T-Builder subsystems under T-Kernel. Specifications for a standard development

NOVEMBER–DECEMBER 2002 55 T-ENGINE

Table 3. Current T-Engine hardware products.

Flash Release CPU model Clock RAM memory month Models Vendor Speciﬁcation (series) (MHz) (Mbytes) (Mbytes) (2002) h101 Hitachi T-Engine SH7727 (SH3-DSP) 96 32 8 July m301 Mitsubishi Electric µT-Engine M32104 (M32R) 216 16 4 September n101 NEC T-Engine VR5500-400 (MIPS) 400 128 16 November n301M NEC µT-Engine VR4191-200 (MIPS) 200 32 16 November y101 Yokogawa Digital Computer T-Engine ARM720T (ARM) 72 32 8 October

environment ensure the portability of mid- on T-Engine and T-Kernel. For example, the col- dleware and application software. Due to its lection might contain a small library consisting nature, T-Engine first requires a common of tree programs, a sorting function, a searching development environment compatible with function, various encryptions and signatures, data multiple CPUs, and, secondly, an open devel- compression algorithms, and data format trans- opment environment. We have defined T- lations. It could also include basic resident pro- Builder, a minimum and basic standard grams, such as those for TCP/IP, and file systems development environment, and adopted the based on file allocation tables. T-Collection is sim- GNU development environment. T-Builder ilar to the ACM Collected Algorithms (http:// is simply a reference standard environment www.acm.org/calgo) collection and, more impor- intended for building T-Engine middleware. tantly, is in a standard format that makes it easy to Development environment vendors will most run code immediately. Normally, the T-Engine likely offer better development environments Forum will provide these algorithms in source that feature compatibility with T-Builder. code format but will offer some in binary format. The T-Engine Forum collects the content of T- T-Format Collection, referees it, and releases it. T-Format is a set of standard software formats for T-Engine middleware distribution. T-Dist T-Format consists of a binary-code format, The T-Dist framework aids Internet distrib- source code style guidelines, and a document ution of software components built by software format. Software formatted according to T- vendors using T-Format. When a vendor regis- Format will run on target systems that satisfy ters a middleware package at the T-Engine T-Engine and T-Kernel specifications. The T- Forum, other users can search for it on the T- Builder basic software development environ- Dist software database. T-Dist’s licensing mech- ment handles source code and binary code anism also enables license management based on T-Format. We use C, C++, and Java operations, such as for settling payments related as basic languages for standardization. to distribution. To provide this licensing mech- We have employed the executable and link- anism, middleware handles billing procedures ing format (ELF) as the binary code format and and manages protected execution in coordina- Dwarf as the debug symbol format. To prevent tion with an eTRON secure chip. By using the symbol collisions when linking multiple micropayment, cipher, and authentication func- libraries, T-Format defines the naming rules and tions offered by eTRON, this middleware pro- header file format for such global symbols as vides a framework for various middleware global variables and exported functions. Regard- licenses. For example, implementations can ing source code style, it’s crucial to avoid sym- include settings that permit execution only on bol collision when linking libraries. The naming eTRON systems that store a certain encryption rules defined in binary format for global sym- key. The key is delivered according to the source bols apply directly to the source code format. code license, thus preventing unlicensed system use. As another example, we can realize a pay- T-Collection ment mechanism in which the price depends on T-Collection is a basic set of software that runs the number of times a particular software runs.

56 IEEE MICRO Figure 5. Hitachi h101, designed using the Figure 6. Mitsubishi m301, designed using standard T-Engine speciﬁcation. the µT-Engine speciﬁcation.

he T-Engine Project announced its World,” Trans. ACM Internet Technology, Tframework in December 2001. After fur- vol. 1, no. 1, Aug. 2001, pp. 70-109. ther research and development, the project 6. A. Schmidt and M. Beigl, “New Challenges inaugurated the T-Engine Forum in June of Ubiquitous Computing and Augmented 2002 to engage in T-Engine research and Reality,” Proc. 5th CaberNet Radicals development. As of August 2002, 50 compa- Workshop, 1998; http://www.teco. nies have participated in the forum. As listed uni-karlsruhe.de/~albrecht/cabernet/ in Table 3, all engine-related hardware released ubicomp1.html. thus far concerns T-Engine (Figure 5) and µT- 7. K. Sakamura and N. Koshizuka, “The eTRON Engine (Figure 6), and covers the main CPU Wide-Area Distributed-System Architecture architectures such as Hitachi’s SH, Mit- for E-Commerce,” IEEE Micro, vol. 21, no. subishi’s M32R, MIPS, and ARM. MICRO 6, Dec. 2001, pp. 7-13.

References 1. K. Sakamura, “The TRON Project,” IEEE Ken Sakamura’s biography appears in the the Micro, vol. 7, no. 2, Apr. 1987, pp. 8-14. Guest Editor’s Introduction starting on page 2. D.C. Sharp, “Reducing Avionics Software 7 of this issue. Cost Through Component Based Product Line Development,” Proc. Software Tech- Noboru Koshizuka is an associate professor at nology Conf., 1998; http://www.stc-online. the Information Technology Center, Univer- org/cd-rom/1998/slides/t9dsharp.PDF. sity of Tokyo, and is assistant director at YRP 3. D.C. Schmidt, “Middleware for Real-Time Ubiquitous Networking Laboratory. His and Embedded Systems,” Comm. ACM, research interests include ubiquitous comput- vol. 45, no. 6, June 2002, pp. 43-48. ing, operating systems, and interactive systems. 4. A. Householder, K. Houle, and C. Dougberty, Koshizuka has a BS, MS, and PhD, all in infor- “Computer Attack Trends Challenges mation science, from the University of Tokyo. Internet Security,” IEEE Security & Privacy He is a member of the IEEE and the ACM. supplement, Computer, vol. 35, no. 4, Apr., 2002, pp. 5-7; http://computer.org/security/. Direct questions and comments about this 5. M.S. Blumenthal and D.D. Clark, article to Ken Sakamura, Univ. of Tokyo, 7-3- “Rethinking the Design of the Internet: The 1 Hongo, Bunkyo-ku, Tokyo 113-0033, End-to-End Arguments vs. the Brave New Japan; [email protected].

NOVEMBER–DECEMBER 2002 57