At present, the development of various embedded devices, such as cell-phones, digital cameras, and PDAs, is being actively carried out, and large numbers of embedded devices are making their way to market in the world one after the other.
Nevertheless, it could not be said that the development environments and software environments of embedded devices up to now have been arranged in a manner that inspires flattery. My reason for saying this is because there was a problem in which there were many cases where it became necessary to take another look at the software from the source code when implementing on a different target where the software and the OS couldn't absorb the target board and CPU differences. Due to this, there were not just a few cases of embedded device development costs increasing to the extent that the type and version of the development target changed.
In the middle of all this, T-Engine appeared. As a result of the appearance of this T-Engine platform, it has become possible for software that has heretofore been reexamined for each target and CPU to run through something on the order of recompiling. By utilizing this common platform called T-Engine in this manner, it has become possible to receive great merits in the embedded device development scene. Furthermore, by distributing software that runs on top of T-Engine using the T-Dist scheme, it becomes possible to attempt to raise development productivity even more.
T-Dist refers to a scheme for distributing middleware that runs on top of T-Engine, Dist being an abbreviation of Distribution. The objectives of this T-Dist lie in distributing middleware that runs on the common embedded platform called T-Engine and raising the development productivity of embedded devices.
Through T-Dist, we distribute binary format middleware that has already been compiled (we also assume that in the future we will distribute middleware as source code). Just by linking to a target or dynamically loading, it becomes possible for us to run middleware. Here, there might be some people who worry that when we distribute middleware through binaries, we must prepare various types of binaries because the environments are different based on the target and CPU. Certainly, with T-Engine, which serves as the running environment for the middleware we distribute via T-Dist, it becomes necessary to distribute after compiling and creating binaries for every board type, because the middleware binaries are different for each CPU. However, this isn't a big problem, because it is possible for the middleware vendors to distribute after creating binaries compatible with the various CPUs through something on the order of recompiling, since they are utilizing T-Engine.
In this manner, by means of distributing middleware that runs on top of T-Engine, it becomes possible to rapidly raise the development productivity of embedded devices.
At present, we are in the process of constructing a center for distributing middleware inside the T-Engine Forum, and we are planning to actively distribute middleware hereafter.
I will briefly explain the T-Dist scheme [Fig. 1]. First, the middleware vendors (1) create middleware, and then they carry out a registration request to the T-Engine Forum (2). License control middleware (3) (mentioned below) is added to middleware for which a request has been made, and then it is released on the T-Engine Forum's Web site (4).
|
|
|
Embedded device makers access the Web site through which the T-Engine Forum provides the middleware distribution service (5), carry out a middleware search, download the necessary middleware onto the development environment host, and embed it on the target. Also, they purchase the required license in order to run the middleware (6), and they download it inside the eTRON chip mounted on the target (7).
When executing the middleware, the existence of the license that permits the execution of the middleware inside the eTRON chip on the target is confirmed, and when it passes through the check, the middleware runs (8).
In the previous section, I wrote that we control the running of middleware based on a license, but in concrete terms, in what way are we carrying out this control?
For example, this operates in a form in which in cases where there have been implemented in the license control software conditions such as "charge at the time of execution" or "is in possession of a license," when the middleware is executed on top of the target, the control middleware goes into action and "charge processing" or "license confirmation processing" is carried out, and when it is judged that there are no problems, the middleware is executed.
So then, in what manner do we protect security while carrying out each of the processes mentioned above? For that purpose, we utilize the mechanism of the eTRON chip. The eTRON chip is specialized hardware in an independent module that possesses strong tamper proof features, and by storing licenses and electronic money inside this tamper proof chip, it becomes possible to execute secure license management and charge processing. Charges and execution control for middleware based on this mechanism are executed securely on top of the eTRON chip. In addition to the above, in cases where electronic money is utilized in charge processing, it becomes possible to offer finely detailed services, such as it becoming possible to cope even with micropayments of the kind where several hundredths of a yen to several yen are charged for each time one executes middleware.
Moreover, by separating the middleware and the license in this manner, there is nothing to block the distribution of the middleware itself. As we have made it so that one will purchase a license after it is noticed at first that a license is lacking following the execution of middleware, we are preventing the illegal utilization of middleware, and thus it becomes possible to carry out the distribution of middleware.
Middleware that is the object of T-Dist can cope across a wide range, not just with embedded device development locations, but up to applications aimed at users. Also, on this occasion the topic has been made specific to the distribution of "middleware," but what can utilize T-Dist are not topics limited to middleware. By preparing a license that can cope with contents, it becomes possible to carry out license confirmation when contents are read in. For example, it is possible to securely distribute even movie type image data by introducing a system in which one stores in advance in a license a decoding key for encoded distributed image data that are decoded when those data are called up.
Also, besides the above mentioned system, it is also possible to introduce a scheme in which one embeds license confirmation logic in the loader itself that loads middleware into memory, and then carry out license confirmation at the time of loading. In the case of this system, it becomes unnecessary to embed middleware for license control in middleware.
As for issues, one could mention raising the processing speed at the time of license confirmation, early startup of the middleware market, and so on, but slowly increasing the number of middleware distributed from here on, and raising the development productivity of embedded devices to the utmost limits are the objectives of T-Dist.
The above article on T-Engine appeared on pages 32-33 in Vol. 84 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 2003 Personal Media Corporation
Copyright © 2003 Sakamura Laboratory, University Museum, University of Tokyo