We have been involved in the development of a plant monitoring system for a certain large iron-manufacturing company (because of the circumstances involved, I cannot release the real name) from several years ago. Because the operating system (OS) we had been using at the time became incapable of satisfying the functions/requirements the user demanded, we ended up conducting a study to adopt a new OS. Accordingly, as the result of a comparative study of various OS candidates for adoption as a new OS, we decided on BTRON. In this paper, I will explain the story from a technical point of view, and I would also like to discuss my expectations for BTRON in the future.
Incidentally, ITRON is prominent among the OSs being utilized for embedded systems use in the field of factory automation (FA). However, in fields where human-machine interface (HMI) functions are required, there are various ones, such as "real-time UNIX based on UNIX," "a real-time OS dependent on DOS for HMI functions," "a real-time OS with added HMI functions based on an OS for embedded systems," etc. But it seems there is still no leading OS of this type due to such reasons as expensive licensing fees, the functional inadequacy of many parts, and the need to perform system generation.
The real-time OS we had been using is a "real-time OS with added HMI functions based on an OS for embedded systems." For the HMI functions, a character-based screen and a graphic-based screen were standard, and since the response speed was also sufficient in the past when CPUs were not powerful, it was suitable for constructing FA systems. This situation continued for several years during which a fair number of systems were constructed and the building up of assets made progress. Putting this experience to use, it became possible for us to construct a portion of a system premised on a large-scale network by combining personal computers and the real-time OS, which in the past was thought to be impossible except with a process computer.
In circumstances such as these, the appearance and spread of [Microsoft Corp.'s] Windows gradually influenced even the field of FA. In particular, the user came to strongly demand that we construct systems using windows in the HMI. Since there were a fair amount of software assets that had been amassed in the past, systems development involving new equipment would not have been that difficult. However, the modification of existing equipment, in particular the reconstruction of systems by changing the OS employed in them, was not something that was going to be easy. In addition, we anticipated that the fact Windows is not a real-time OS is something that would become the greatest obstacle when employing it in FA. Nevertheless, we could not ignore the inclinations of the user, so by means of a topic in which there was comparative leeway in both development period and development costs, in parallel with developing a system with the previous real-time OS, we developed a system on the same specification (screens and the like according to a similar specification) with Windows also, and then we conducted a performance evaluation. As a result, it was judged that the system could not be used in actual service, just as we had predicted. The reason was that "loss of input data" sometimes occurred, which was because of the lack of real-time performance.
Why is even "loss of input data" that occurs rather infrequently something that must not happen? This is because in the field of FA, in keeping with the automation of production lines, the "informationalization" of production facilities has moved forward. Various equipments on production lines have had various types of sensors installed in them, and "equipment diagnosis systems" that monitor for breakdowns while continuously taking in data from those equipments have been installed in large numbers. Also, "intelligent terminal devices" have been installed in large numbers. These have functions that receive individual product specifications from a host computer via a network and display instructions to the operator, and which send product manufacturing data input by the operator to the host computer via a network. Thus data loss must absolutely be removed, since it is something that would damage the reliability of the production system. Moreover, what has to be removed even more than "loss of input data" is the so-called system down (hangup). Because the production line stops when this occurs, it results in a "serious equipment accident" that leaves production planning in disorder.
Thus we decided to first do a current survey of OSs on the market to see if there was something that could serve as a next-age OS that would satisfy both the demands of the user and the technical standards demanded in the FA field. The basic prerequisites given were that real-time processing, multitasking, a multiwindow system, a high-speed file system, and Japanese-language display and input be standard features of the OS. We received materials from makers of seemingly applicable OSs, and we studied them by creating a comparison table for each item. The result of this was that BTRON and another certain OS remained as the leading candidates. When we compared these two OSs, based on the fact that in contrast to BTRON, which is a 16-bit OS and lacks network support, the other OS is 32-bit and also supports networks, BTRON was at a disadvantage if we had to make a choice. But then, two more requirements were additionally submitted by the user as selection requisites. The first was that the OS to be selected is to be a general-purpose product (a product on the general market), and the second was that the OS to be selected is to run on both NEC Corp.'s 9800 series and IBM PC-AT compatibles. BTRON satisfied both of these requirements, but since the other OS was unable to satisfy the two of them, it was finally dropped from selection. Thus the final remaining one was the BTRON-specification OS "1B/V1."
From these circumstances, 1B/V1 was almost at the point of being decided upon as a next-age OS candidate, but the user strongly demanded that they wanted to directly hear the policies and so on from the maker doing the marketing before a decision making a final decision. Through a visit and question and answer session with Personal Media Corp., which accepted this, the user acquired an understanding of BTRON, and "BTRON" was finally decided upon as a next-age OS candidate. As a result of this, we and our user came to jointly begin evaluation testing of BTRON.
Through these developments, BTRON was selected as a next-age real-time OS candidate, following which we purchased a development system from Personal Media Corp. and began evaluation testing. A summary of the items for evaluation are as follows:
In order to evaluate these, we decided to make a SCSI driver and [temperature] confirmation monitor as development targets, which we evaluated over the course of about a year.
In regard to (1), first, together with joining Personal Media Corp.'s "BTRON software development organization," we concluded a separate contract and obtained the "driver interface specification." In addition, we purchased a SCSI board from a board maker, and then we started development. Since sample driver source files are appended to the "driver interface specification," and because the development language is also C language, development proceeded comparatively smoothly, in particular without any technical problems occurring. Moreover, we concluded a separate contract for "support for the driver interface specification," and made one inquiry after another about problem points and points that were not clear. Because we were able to obtain kindly detailed responses to our questions, these were solved at an early stage. As a result, because we were able to develop something that ran according to specification for the time being, our evaluation on this point was "okay."
As for (2), what we placed importance on in particular was "process switching time" and "response speed of the window system." Using a system with an Intel 80486DX2 CPU and 16 megabytes of main memory, we were able to obtain satisfactory results. However, since the number of cases evaluated concerning this item was so few, it was given an "okay for now" evaluation.
Concerning (3), through the kindness of Personal Media Corp., we were provided with a "guide to creating the outer kernel," but we still haven't evaluated it. We would like to decide on a development target as soon as possible and implement it.
With regard to (4), a separate support contract is required, but since it was possible to clear up doubtful and unclear points through questions and responses via facsimile in a timely manner, our evaluation was "okay." Also, we received an agreeable response even for the provision of materials and so on that we asked for. Of course, we think the support from the maker is indispensable.
As concerns (5), we performed cross development on top of DOS; since we could use the wealth of tools that run on DOS, it was possible to easily carry out the development work. However, since this was cross development, some effort was required to perform it while switching between DOS and BTRON on a single machine. Of course, we think two machines, a development machine and an execution machine, are required. In addition, the specification for the C language that is the development language is old, and it was a nuisance that macros cannot be used by the assembler. These points are things that we would like improved without delay.
Based on the fact that the result of the general evaluation was "pass," we next moved on to developing the system in the actual topic using BTRON. The specification of requirements for the topic that was to be the development target are as follows:
Development target:
Collection data:
Sampling frequency:
Operation time:
Display data:
Data display time:
Display data editing method:
Startup method:
This is a temperature graph previously output with a pen recorder that was moved to a CRT display, along with an added function. The function compares a point to which the temperature has suddenly dropped from its surroundings with a set value (set with the panel item "Deciding gap" in Fig. 2), makes a judgement, and then displays its position ("Gap confirmed" in Fig. 1).
As for their locations, the very top of the graph is the latest time (the time is displayed with "present" time in the upper right hand corner of the screen); since the standard is 150 seconds (vertical axis), if we look at the locations where "gap confirmed" is displayed, it is possible to surmise the vicinity of the defective product that passed through and the number of places where there are temperature abnormalities. When one would like to view more detailed locations, it is made up so that one can also switch (Fig. 4) the vertical time axis to 25 seconds (Fig. 3). In the past, after outputting the temperature graph with a pen recorder, the operator on location looked at this temperature graph and then made a judgment as to whether or not there were abnormalities. However, with this method, the product had already passed completely through the processing machinery, so there was a problem in that the point in time of the judgement was late. To improve this, we sample the temperature data before processing machinery passage, and then display the graph in real time on a CRT screen. If for argument's sake the occurrence of an abnormality is confirmed, it is necessary to take actions that make it possible to suspend operation immediately, and as such this system is something that was planned for renovating the equipment.
Three things were created for this topic: an "analog board," a "data collection process," and a "data editing/display process" (Fig. 5). It was completed in about four months, including on-location testing. What became a problem during the development process was that there were occasionally instances of the analog board we employed not initializing normally. We explained the situation to the board maker and had them carry out confirmation tests. However, the reply was that "we are not able to confirm any abnormalities in particular." Accordingly, we attempted to find the clue to a solution by analyzing with an analyzer the hardware signal behavior states both when initialization went well and when it did not go well, and we tried to find differences attributable to computer types by changing the computer to a different model. However, in the end, we were unable to identify the cause. As a result of thinking up and trying out various plans that ought to solve this problem, we established that if we issued the initialization command twice to the analog board, it always ran normally. Through this method, we avoided this problem.
We received a favorable evaluation from the production site without any particular problems being pointed out. They especially liked the point that the screen size had been markedly improved from the 640 x 400-dot of the past with 800 x 600-dot super video graphics array (SVGA), and there was little incompatibility, since the graph had been made up so that it is displayed flowing from the top of the screen to the bottom in the manner of the conventional pen recorder.
Using this as a step, we aimed at the order received for the next topic, and then proposed a system that used BTRON as the OS, but one of the user's requirements was that it was necessary for the screen size to be extended graphics array (XGA) of 1,024 x 768 dots or above. Accordingly, we consulted with Personal Media, and we received the response that this would be possible if we specified a display board. We relayed that intention to the user. However, on the pretext that a basic part such as the display device was not standard in the system, we were unable to receive an order for this topic with BTRON.
Concerning the acceptance of the order for this topic, there is a behind-the-scenes story. The person in charge on the user's side strongly insisted that he wanted to carry out system development with a certain OS of the Windows line, which had been taken up a lot in computer magazines. Moreover, because of an incorrect rumor in circulation that this OS is "real time" (what!!) it was decided to go with this certain Windows-line OS. As a result, input data losses frequently occurred, so it came about that we had to add an auxiliary device (a data buffering device that used the real-time OS of the past) in order to take in the input data. The additional expenses became the burden of our firm, and the project manager ended up suffering trying to make do. Furthermore, I would like to write down here that the person in charge of development anticipated this would be the result from the beginning, and he advised his superior.
Afterward, each time a new topic appeared, we made a proposal that would lead them to adopting BTRON, but after the collapse of the bubble economy the budgets for topics became correspondingly severe. Due to the fact that there was no leeway to develop new drivers or train BTRON development technicians, we ended up practicing discretion in the adoption of BTRON. What was used was the real-time OS of the past for which there were a lot of experienced people and accumulated software assets.
From our experience, in order to spread BTRON as an OS in the FA field, we think it is necessary to complete provision of the following things.
The first thing that is necessary, we believe, is to develop device drivers for use with input/output devices, such as the analog and digital boards that are frequently used in the FA field, and to provide highly reliable device drivers at low cost. Because there is not an accumulation of software assets for BTRON, even if one intends to adopt it in the FA field, there will be many cases when it will be necessary to carry out development of device drivers in parallel. Since it can be expected that this will lead to a lengthening of the development period and an increase in development costs, users will consider it worth practicing discretion in adopting BTRON.
As for the second thing that is necessary, there is a need to provide an environment for training technicians that includes BTRON programs. This is because although BTRON has a wealth of functions, acquiring a command of these and developing a system requires considerable experience and technical skill. There are libraries, such as an interface part corresponding to a specification and "standard and special application libraries" in the BTRON1 puroguramingu hyoojun handobukku [BTRON1 programming standard handbook], but we strongly feel there is a need for sample programs in which these are systematically brought together and illustrated with examples of their use.
The third thing that is necessary is raising the level of awareness of BTRON. Specifically, increasing the chances that it appears in the computer magazines that companies regularly subscribe to. This, of course, is something that is should be taken for granted. If we limit discussion to the field of FA, there is not necessarily any need for an OS that is to be adopted to be a famous one. However, by introducing it in magazines, we think that anxieties will abate when users newly adopt BTRON, and that resistance to its adoption will weaken.
In addition to these, we shall state as follows the things we would like fixed immediately.
Concerning (1), we are looking forward most of all to the abolition of the so-called 64-bit segment. In keeping with improvements in CPU processing power and enlargement of the main memory, we have been getting lots of requests from the user asking if we cannot process on one machine the system that we distributed and processed on two machines in the past. In cases when we redesign systems, the thing that always becomes an obstacle is this 64-bit segment boundary. Because we are released from this curse when the OS becomes 32-bit, it seems the software system organization becomes fairly simple. Also, we are simultaneously released from the 16 megabyte limit, which is the maximum amount of main memory it is possible for BTRON1 to manage.
As for (2), this means let's end reliance upon others and move forward relying upon on own power. After all is said and done, powerful OSs without exception provide a self-development environment, so if BTRON also is aiming at becoming a powerful OS, we believe it likewise ought to provide self development. We believe this would become a motivation for adopting BTRON.
Item (3) is particularly highly regarded in the field of FA. In cases when we take a backup of accumulated data during periodic inspections, carrying this out while exchanging low-capacity media, such as floppy disk media, several times is something that makes a system a difficult-to-use system needlessly requiring time and effort if it is done by a person working on location. This is the type of thing that would lead to dissatisfaction with a system. Also, because this would cause hindrances due to both the large number of backup media and in securing a place to preserve them, it could be said that the necessity is great because of these factors also.
The reason for (4) is because in the field of FA a great demand has come about to take accumulated data into a workstation and analyze them, and, in addition, to take data in from a machine set up in a remote location using a network. In particular, since there is a strong demand to support the TCP/IP of Ethernet, we believe there is an urgent need to provide this. However, in the closed network environments in the FA field, Ethernet is not used very much because it lacks real-time performance. In many cases network equipment with real-time performance based on a token ring LAN is used. This is something I would certainly like to have BTRON compatible with.
The reason for item (5) is that it is something that will become an important factor in realizing "remote monitoring" and "remote operation," which it is thought will become important factors in the field of FA in the future. Although the amount of data these two media generate is enormous, if they are combined with compression technology and made so that they can be easily used, they can be expected to contribute greatly to the further rationalization of production lines.
Recently, Personal Media announced the marketing of the 32-bit specification OS "3B/V," which is the next generation BTRON. Looking at its main merits and specifications, it seems as if not a few solutions to the problems and realization of the demands mentioned above are being attempted. Thus we are awaiting it with great expectation.
Recently, in addition to previous ones for use with [Microsoft Corp.'s] MS-DOS, various board makers have come to provide device drivers for their firm's board products for use with Windows-line OSs also. It seems this is in anticipation that Windows-line OSs will spread widely also in the field of FA. It is certainly a fact that there are systems that do not require real-time performance in the FA field. Moreover, we have come to frequently hear that system development has become easier to do than in the past following the spread of conversational-type (?) development languages, such as [Microsoft Corp.'s] VisualBasic. However, it is expected that in the future also there will be no change to the fact that in the FA field "systems that require real time" will be in the majority.
BTRON is a rare general-purpose OS that satisfies all the requirements of "real time," "multiprocess," "multiwindow," a "high-speed file system," and "Japanese language loaded on as standard equipment." If, in addition to these, support is provided for "networking," "XGA," and so on, I am certain that it could become the standard OS in the FA field.
The above article on 1B/V1 in factory automation appeared on pages 62-67 in Vol. 50 of TRONWARE . It was translated and loaded onto this web page with the permission of Personal Media Corporation.
Copyright © 1998 Personal Media Corporation
Copyright © 1998 Sakamura Laboratory, University Museum, University of Tokyo