- Email: [email protected]
Microcomputer unit for control of distributed devices over computer networks
-.-
~
JOURNAL OF SYSTEMS ARCHITECTURE
I-
ELSEVIER
Journal of Systems Architecture 43(1997) 81-85
Extended abstract
Microcomputer unit for control of distributed devices over computer networks Gregor Vrecko b
3,
Zmago Brezocnik b,., Tatjana Kapus Andrej Duh a
b,
Bogomir Horvat
b,
a MG.SOFT Corporation, S/ro.mnu)'erje/JlJ 32a. S/·20OO MarilJOr, Slouenia Uniuer,\'i/y o/Marilmr. Faculty afElec/rical EIl8im!eri"g andComputer Science. Smetanoua 17. S/·2OO0 Maribor. Siouenia
Abstract The paper presents 3. Control Node Unit (CNU) which is a small microcomputer designed to control automated electromechanical devices. CNU can control both the stand-alone devices and devices in a distributed connection-oriented environment. The existing infrastructure can be used for communication among eNOs.
1. Introduction The idea of automatizing a living and a working place is relatively old. There are a lot of automatization products installed everywhere. But many of these cannot be connected into a common automated environment. This was the main reason that we started to develop a small microcomputer unit called Control Node Unit-eNU. eNUs should be able to communicate over the infrastructure already installed. CNU should not be application specific. We suggest to assign the CNU to each controllable device. Altogether, the following basic design require-
• Corresponding author. Email: [email protected]
ments for the final CNU tiroduct have been posed. [10,11]: CNU should be small and powerful, it should be designed as an open system, it should support the most often used standard communication protocols, and connection of devices being controlled should be as easy as possible (plug and play). Section 2 briefly describes the CNU hardware. The CND software description is given in Section 3. ''Ale finish '.vi"h a resume of the results and a discussion of possible applications.
2. Hardware Ihe eNU consists of the following modules [9]: computer part, Ethernet interface, Arcnet interface,
1383·7621/0165·6074/97/$17.00 © 1997 Elsevier Science B.V. All rights reserved Pl/ S 1383-7621/0165·6074(96)00105.1
82
G, VreNw et al,/ Journal oj'Sy.rlem.I' Architcctur« 43 (1997) 8/-85
serial communication module, parallel input/output interface, and auxiliary module made of set-up, indication, Flash EPROM programming. and power submodule. The CNU network modules should be used to support communication with other CNUs and the supervisor station in a distribute' automated environment. On the other hand. the serial communication module and the parallel I/O interface are used for connection to the controllable electromechanical devices. Computer part is compound of Intel 80188 compatible NEC V40 CPU, 896 KB RAM and 128 KB flash EPROM. NEC V40 CPU chip has a lot of support logic already integrated (clock generator. interrupt controller, timer/counter, DMA controller, RS 232 serial interface). Therefore, only a little external logic is needed to build a working computer. Ethernet interface is based on the National Semicon-
ductors DP 82902VF chip. The interface consists also of a 32 KB local buffer, network transceivers, and bus logic. It is more or less compatible with the NE 2000 network adapter standard from IBM PC compatible computer world. Data transfer between a 32 KB local buffer and a 896 KB RAM on a computer part is implemented by two DMA channels. ,1 rcnet lnterface is added to the CNU because of its wide usage in factory automatizations. The heart of the Arcnet interface is Standard Microsysterns Corporation's COM 20020 single chip controller. Serial communication module uses standard serial Am85C30 communication controller from Advanced Micro Devices. CNU supports the RS 232 and RS 422 serial interfaces. Parallel l f 0 interface is used for a direct connection to the controlled device. It is designed around two Intel compatible 8255 parallel interface chips. They support parallel data transfer or selection of each line to be either
Fig. I, CNU board and final product outlook.
G. Vreckll et uf.; Jouma! 01Sy.~tem... Architc(.'ture 43 (1997) 81-85
input or ,. ~""l. Flash EPROM programming submodule is "sed lI':cr updating the code in the Flash EPROM. Programming can be done even during CNU normal operation. CNU board and the front panel of the final product are shown in Fig. 1. 3. Software When the hardware had been successfully tested, we started to develop the operating system named MG-OS. First we set some requirements for our operating system. We realized that it has to be small and powerful. We also decided that for our purpose a multitasking (tlmesharing) operating system is better than a sequential (single thread) one since in CNU, several communication and control tasks have to run simultaneously and independent of each other. We used existing multitasking operating systems MINIX [8], XINU [2,3], and UNIX [I] as our references. In contrast to these operating systems, in our MG-OS we do not need to implement all the functions, because it does not run in a multiuser environment and also does not use hard disk functions. But the MG-OS kernel implementation uses the same style offunctions as the mentioned versions of UNIX. MG-OS has all the functions that a multitasking operating system should use to prevent deadlocks and concurrent data accesses from various tasks. T'ie orgnnization of MG-OS is layered. All kernel functions are positioned in low operating system layers. The MG-OS kernel is compound from: process managernent functions including process priority management, process context switching functions and process scheduling functions, process co-ordination functions including semaphores for mutual exclusion, process intercommunication functions including message passing and port functions; memory and stack management functions, real-time clock and interrupt management functions, and device input and output interface functions. An these functions are independent of peripheral
83
devices. AJI other functions within MO-OS operating system are layered higher than kernel functions. They are peripheral device drivers and high-layer communication protocols manipulation functions. eNU has many peripheral devices installed. For all of these devices we implemented device drivers. We designed device drivers in such a way that devices are transparent to concurrent tasks. We implemented a common interface for all input!output functions (open, close, read, write, and control). The rest of the software built into MG-OS are communication protocols manipulation functions. The easiest way to interconnect the computer these days is to use Internet and its standard protocol family, rcelIP [5,6]. The implementation of common protocols in MG-OS is multitask oriented. Communication protocols are organized into four conceptual layers, The lowest is the network access layer which consists of device drivers and the network interface. Network interface is used for specific network datagram encapsulation. eND already supports the Ethernet hardware encapsulation. Arcnet network protocol, SLIP, and PPP serial replIP ereapsulations are i'ar.ned for further applications. Network interface uses ARP and RARP. The next layer is the Internet layer consisting of IP and ICMP protocols. MG-OS uses the daemon task for handling the IP datagrams, IP datagrams are sent by the device drivers to the network demultiplexing function and then to the IP task over the interprocess communication ports. After handling IP datagrams in IP task th·~y are sent to the higher level protocols or back !:o) the network multiplex function and further onto the network. Host-to-host layer is positioned directly above the IP layer. Host-to-bast layer is concerned with the reliable host-to-host communication from one CNU's application task to another. In the host-to-host layer there are TCP and UDP. Upper protocols have to be concerned with UDP reliability. Application entities communicate with entities in host-to-host layer using the simplified standard socket interface which is
84
G. Vrd:ko ct ul./ Journal ofSystemsArchitecture 43 ( 1997) 81-85
invoked by calling the standard input/output access functions (i.e., read, write. open, close, control). One of the distinctions between the network hostto-host layer and the network application layer is that the fermer resides within the operating system but the latter does not. III the network application layer there are all the functions that use the network for communication with other nodes in the network. Higher standard protocols like TELNET, TFfP [6], and SNMP [7J are also included. CNU is not intended to be used in multi-user environment. Only the supervisor of the distributed automated system has access to the CNU's functions. 111at is why we do not need any reliable virtual terminal. In fact, we implemented the TELNET server functions, but only for the sake of testing our TCP protocol implementation. CNU's network applications use UDP protocol. We have implemented several applications that use UDP: simple non-standard TELNET over the UDP, network Echo daemon, CNU discovery client, network time client, TFrP server, and SNMP. Simple non-standard TEL/'./ET over the UDP is used as a virtual terminal, because then there is no need to put the TCl' protocol into the operating system. Using this application we save some space in the CNU's ROM. Besides, network functions run a little faster if there is no TCP handling. It is true that this application can communicate only with our software in the supervisor station, but why should we allow any ether non-authorised person except the supervisor to access the CND? Network Echo daeman is a standard application for discovering whether UDP or Tep protocol is present in a remote system. We use this daemon also for another purpose. If data structure carried by Echo Reply datagram matches our unique signature, echo application invokes the CNU discovery tool which returns the necessary information about the system back to the caller. This daemon makes us possible to use the standard protocol port to discover the eNDs in the network and to retrieve the: necessary information from each of them.
V!e do not have to use any special protocol port for the eND d~ scovering application. CNU discovery client periodically generates Echo packets and in such a way seeks for any other CNU in the network. It retrieves all necessary Information from other CNUs in the network and updates its local database. The periodically updated rlatabase is available for other applications that need information about connected CNLT~ in the network. Network time client is used to retrieve the correct network time from the time server. By using this function, eND determines real time and thus no battery-backup real-time clock is needed. TFTP server is invoked when updating the system software. New software is transferred to the node using TFTP. After that the flash memory is reprogrammed and the system is restarted. This protocol enables updating of software anywhere in the Internet from a remote location. SNMP is used to control the devices with a standard protocol. It is tree organized and the information is contained in the leafs. SNMP software in CNU uses the standard Internet MIB-II for TCPlIP information transfer and our own subtree for control and management information transfer. Standard MIBs are defined in RFC standards. SNMP is not straightforward encoded like IP or TCP protocols, but it uses ASN.l. This makes the software more complex. In fact, SNMP software is the most complex CNU application until now.
4. Conclusion
We have presented our microcomputer-based Control Node Unit which is intended to be a general entry node for controllable electromechanical devices in a disn ibuted automated environment. Standard computer networks are used for communication among eNDs and between each CNU and a supervisor station. CND is a very powerful small microcomputer with many communication interfaces. It can operate in several distributed cornmunication-ori-
G. vreika et al./Journal ofSy.wems Architecture 43 (1997) 81-85
ented control environments, and also as a stand-alone unit not using any of its communication capabilities. CNU development was supported by Abit Corporation, Tokyo, Japan. CNU hardware design and implementation took only two months from. the product idea to the first working CNU boards. Software development has been much more complicated and time consuming. During software development we have used our own previous product - MONET LAN Analyzer [12]. Currently, CN U software amounts to about 100 KB of executable code. Thanks to replIP we can access our CNUs all over the world through Internet. We can test the CNU's operation and update the CNU's software remotely over Internet. eNU's general communication software is completed. We concentrate our further work on writing application software. It is our opinion that one of very suitable application domains of our product is hotel automatization. In the future, we also plan to apply our product in industry environments, flats, and in integrated home automatization systems.
Acknowledgment We are very grateful to Mr. Takeo Hiyama, president of Abit Corporation, Tokyo, Japan, who financially and with his great experiences helped us to develop the CNF.
85
References [I] M. Bach, TIre Design of the UNIX Opewtillg System, Prentice-Hail, Internal. Editions, Englewood Cliffs, NJ, 1986. [2] D. Comer. Operating Systons Design, The Kinu Approach, Prentice-Hall. Englewood Cliffs, NJ, 1987. [3] D. Comer, Operating Systems Design - Vol. 1/: lnternetworking with Xi"II., Prentice-Hall, Englewood Cliffs, NJ, 1987. [4] D. Comer, lnternetworking with TCP / IP: Principles, Protocols. and Architecture. Prentice-Hall, Englewood Cliffs. NJ, 1988. [5] D. Comer, D. Stevens, lntemetworking with TCP / IP, Vol. II: Design, lmplemenuuian, and lntemals, Prentice-Hall, Englewood Cliffs, NJ, 1991. [6] D. Comer, D. Stevens. lnternetworking with tcr/ IP. Vol. Ill: Client-Server Progranu ling and Applications, PrenticeHall, Englewood Cliffs, NJ. 1993. [7] M. Milkr, Managing lmemetworks with SNMP, M & T Books, 1993. [8] A. Tanenbaum, Operating Systems - Design lind lmplementution, Prentice-Hall. Internal. Editions, Englewood Cliffs, NJ, 1987. [9] G. Vrecko, Control Node Unit 'Tecl",ic(;; .'I1m/lIa', Data book, Abit Corporation & MG-SOFT d.o.o., 1993. (10] G. Vrecko, A general microcomputer unit for distributed control of electrical devices over a communication network, Diploma work, Faculty of Technical Sciences, Mariboi, Slovenia, 1993 (in Slovene). [II] G. Vrecko, Z. Brezocnik and T. Kapus, A microcomputer unit for distributed control of systems in computer networks, Prac. Third Electrotechnical and Computer Science Conl ERK'94, Portoros, Slovenia, Vol. A, pp. 142-145, 1994 (in Slovene). [12] M. Vrecko, MONET - Ethernet M(1nif()ril/:~ System. Users manual, Abit Corporation, 1996, WEB URL: http:/ / www.mg-soft.sij.
~
JOURNAL OF SYSTEMS ARCHITECTURE
I-
ELSEVIER
Journal of Systems Architecture 43(1997) 81-85
Extended abstract
Microcomputer unit for control of distributed devices over computer networks Gregor Vrecko b
3,
Zmago Brezocnik b,., Tatjana Kapus Andrej Duh a
b,
Bogomir Horvat
b,
a MG.SOFT Corporation, S/ro.mnu)'erje/JlJ 32a. S/·20OO MarilJOr, Slouenia Uniuer,\'i/y o/Marilmr. Faculty afElec/rical EIl8im!eri"g andComputer Science. Smetanoua 17. S/·2OO0 Maribor. Siouenia
Abstract The paper presents 3. Control Node Unit (CNU) which is a small microcomputer designed to control automated electromechanical devices. CNU can control both the stand-alone devices and devices in a distributed connection-oriented environment. The existing infrastructure can be used for communication among eNOs.
1. Introduction The idea of automatizing a living and a working place is relatively old. There are a lot of automatization products installed everywhere. But many of these cannot be connected into a common automated environment. This was the main reason that we started to develop a small microcomputer unit called Control Node Unit-eNU. eNUs should be able to communicate over the infrastructure already installed. CNU should not be application specific. We suggest to assign the CNU to each controllable device. Altogether, the following basic design require-
• Corresponding author. Email: [email protected]
ments for the final CNU tiroduct have been posed. [10,11]: CNU should be small and powerful, it should be designed as an open system, it should support the most often used standard communication protocols, and connection of devices being controlled should be as easy as possible (plug and play). Section 2 briefly describes the CNU hardware. The CND software description is given in Section 3. ''Ale finish '.vi"h a resume of the results and a discussion of possible applications.
2. Hardware Ihe eNU consists of the following modules [9]: computer part, Ethernet interface, Arcnet interface,
1383·7621/0165·6074/97/$17.00 © 1997 Elsevier Science B.V. All rights reserved Pl/ S 1383-7621/0165·6074(96)00105.1
82
G, VreNw et al,/ Journal oj'Sy.rlem.I' Architcctur« 43 (1997) 8/-85
serial communication module, parallel input/output interface, and auxiliary module made of set-up, indication, Flash EPROM programming. and power submodule. The CNU network modules should be used to support communication with other CNUs and the supervisor station in a distribute' automated environment. On the other hand. the serial communication module and the parallel I/O interface are used for connection to the controllable electromechanical devices. Computer part is compound of Intel 80188 compatible NEC V40 CPU, 896 KB RAM and 128 KB flash EPROM. NEC V40 CPU chip has a lot of support logic already integrated (clock generator. interrupt controller, timer/counter, DMA controller, RS 232 serial interface). Therefore, only a little external logic is needed to build a working computer. Ethernet interface is based on the National Semicon-
ductors DP 82902VF chip. The interface consists also of a 32 KB local buffer, network transceivers, and bus logic. It is more or less compatible with the NE 2000 network adapter standard from IBM PC compatible computer world. Data transfer between a 32 KB local buffer and a 896 KB RAM on a computer part is implemented by two DMA channels. ,1 rcnet lnterface is added to the CNU because of its wide usage in factory automatizations. The heart of the Arcnet interface is Standard Microsysterns Corporation's COM 20020 single chip controller. Serial communication module uses standard serial Am85C30 communication controller from Advanced Micro Devices. CNU supports the RS 232 and RS 422 serial interfaces. Parallel l f 0 interface is used for a direct connection to the controlled device. It is designed around two Intel compatible 8255 parallel interface chips. They support parallel data transfer or selection of each line to be either
Fig. I, CNU board and final product outlook.
G. Vreckll et uf.; Jouma! 01Sy.~tem... Architc(.'ture 43 (1997) 81-85
input or ,. ~""l. Flash EPROM programming submodule is "sed lI':cr updating the code in the Flash EPROM. Programming can be done even during CNU normal operation. CNU board and the front panel of the final product are shown in Fig. 1. 3. Software When the hardware had been successfully tested, we started to develop the operating system named MG-OS. First we set some requirements for our operating system. We realized that it has to be small and powerful. We also decided that for our purpose a multitasking (tlmesharing) operating system is better than a sequential (single thread) one since in CNU, several communication and control tasks have to run simultaneously and independent of each other. We used existing multitasking operating systems MINIX [8], XINU [2,3], and UNIX [I] as our references. In contrast to these operating systems, in our MG-OS we do not need to implement all the functions, because it does not run in a multiuser environment and also does not use hard disk functions. But the MG-OS kernel implementation uses the same style offunctions as the mentioned versions of UNIX. MG-OS has all the functions that a multitasking operating system should use to prevent deadlocks and concurrent data accesses from various tasks. T'ie orgnnization of MG-OS is layered. All kernel functions are positioned in low operating system layers. The MG-OS kernel is compound from: process managernent functions including process priority management, process context switching functions and process scheduling functions, process co-ordination functions including semaphores for mutual exclusion, process intercommunication functions including message passing and port functions; memory and stack management functions, real-time clock and interrupt management functions, and device input and output interface functions. An these functions are independent of peripheral
83
devices. AJI other functions within MO-OS operating system are layered higher than kernel functions. They are peripheral device drivers and high-layer communication protocols manipulation functions. eNU has many peripheral devices installed. For all of these devices we implemented device drivers. We designed device drivers in such a way that devices are transparent to concurrent tasks. We implemented a common interface for all input!output functions (open, close, read, write, and control). The rest of the software built into MG-OS are communication protocols manipulation functions. The easiest way to interconnect the computer these days is to use Internet and its standard protocol family, rcelIP [5,6]. The implementation of common protocols in MG-OS is multitask oriented. Communication protocols are organized into four conceptual layers, The lowest is the network access layer which consists of device drivers and the network interface. Network interface is used for specific network datagram encapsulation. eND already supports the Ethernet hardware encapsulation. Arcnet network protocol, SLIP, and PPP serial replIP ereapsulations are i'ar.ned for further applications. Network interface uses ARP and RARP. The next layer is the Internet layer consisting of IP and ICMP protocols. MG-OS uses the daemon task for handling the IP datagrams, IP datagrams are sent by the device drivers to the network demultiplexing function and then to the IP task over the interprocess communication ports. After handling IP datagrams in IP task th·~y are sent to the higher level protocols or back !:o) the network multiplex function and further onto the network. Host-to-host layer is positioned directly above the IP layer. Host-to-bast layer is concerned with the reliable host-to-host communication from one CNU's application task to another. In the host-to-host layer there are TCP and UDP. Upper protocols have to be concerned with UDP reliability. Application entities communicate with entities in host-to-host layer using the simplified standard socket interface which is
84
G. Vrd:ko ct ul./ Journal ofSystemsArchitecture 43 ( 1997) 81-85
invoked by calling the standard input/output access functions (i.e., read, write. open, close, control). One of the distinctions between the network hostto-host layer and the network application layer is that the fermer resides within the operating system but the latter does not. III the network application layer there are all the functions that use the network for communication with other nodes in the network. Higher standard protocols like TELNET, TFfP [6], and SNMP [7J are also included. CNU is not intended to be used in multi-user environment. Only the supervisor of the distributed automated system has access to the CNU's functions. 111at is why we do not need any reliable virtual terminal. In fact, we implemented the TELNET server functions, but only for the sake of testing our TCP protocol implementation. CNU's network applications use UDP protocol. We have implemented several applications that use UDP: simple non-standard TELNET over the UDP, network Echo daemon, CNU discovery client, network time client, TFrP server, and SNMP. Simple non-standard TEL/'./ET over the UDP is used as a virtual terminal, because then there is no need to put the TCl' protocol into the operating system. Using this application we save some space in the CNU's ROM. Besides, network functions run a little faster if there is no TCP handling. It is true that this application can communicate only with our software in the supervisor station, but why should we allow any ether non-authorised person except the supervisor to access the CND? Network Echo daeman is a standard application for discovering whether UDP or Tep protocol is present in a remote system. We use this daemon also for another purpose. If data structure carried by Echo Reply datagram matches our unique signature, echo application invokes the CNU discovery tool which returns the necessary information about the system back to the caller. This daemon makes us possible to use the standard protocol port to discover the eNDs in the network and to retrieve the: necessary information from each of them.
V!e do not have to use any special protocol port for the eND d~ scovering application. CNU discovery client periodically generates Echo packets and in such a way seeks for any other CNU in the network. It retrieves all necessary Information from other CNUs in the network and updates its local database. The periodically updated rlatabase is available for other applications that need information about connected CNLT~ in the network. Network time client is used to retrieve the correct network time from the time server. By using this function, eND determines real time and thus no battery-backup real-time clock is needed. TFTP server is invoked when updating the system software. New software is transferred to the node using TFTP. After that the flash memory is reprogrammed and the system is restarted. This protocol enables updating of software anywhere in the Internet from a remote location. SNMP is used to control the devices with a standard protocol. It is tree organized and the information is contained in the leafs. SNMP software in CNU uses the standard Internet MIB-II for TCPlIP information transfer and our own subtree for control and management information transfer. Standard MIBs are defined in RFC standards. SNMP is not straightforward encoded like IP or TCP protocols, but it uses ASN.l. This makes the software more complex. In fact, SNMP software is the most complex CNU application until now.
4. Conclusion
We have presented our microcomputer-based Control Node Unit which is intended to be a general entry node for controllable electromechanical devices in a disn ibuted automated environment. Standard computer networks are used for communication among eNDs and between each CNU and a supervisor station. CND is a very powerful small microcomputer with many communication interfaces. It can operate in several distributed cornmunication-ori-
G. vreika et al./Journal ofSy.wems Architecture 43 (1997) 81-85
ented control environments, and also as a stand-alone unit not using any of its communication capabilities. CNU development was supported by Abit Corporation, Tokyo, Japan. CNU hardware design and implementation took only two months from. the product idea to the first working CNU boards. Software development has been much more complicated and time consuming. During software development we have used our own previous product - MONET LAN Analyzer [12]. Currently, CN U software amounts to about 100 KB of executable code. Thanks to replIP we can access our CNUs all over the world through Internet. We can test the CNU's operation and update the CNU's software remotely over Internet. eNU's general communication software is completed. We concentrate our further work on writing application software. It is our opinion that one of very suitable application domains of our product is hotel automatization. In the future, we also plan to apply our product in industry environments, flats, and in integrated home automatization systems.
Acknowledgment We are very grateful to Mr. Takeo Hiyama, president of Abit Corporation, Tokyo, Japan, who financially and with his great experiences helped us to develop the CNF.
85
References [I] M. Bach, TIre Design of the UNIX Opewtillg System, Prentice-Hail, Internal. Editions, Englewood Cliffs, NJ, 1986. [2] D. Comer. Operating Systons Design, The Kinu Approach, Prentice-Hall. Englewood Cliffs, NJ, 1987. [3] D. Comer, Operating Systems Design - Vol. 1/: lnternetworking with Xi"II., Prentice-Hall, Englewood Cliffs, NJ, 1987. [4] D. Comer, lnternetworking with TCP / IP: Principles, Protocols. and Architecture. Prentice-Hall, Englewood Cliffs. NJ, 1988. [5] D. Comer, D. Stevens, lntemetworking with TCP / IP, Vol. II: Design, lmplemenuuian, and lntemals, Prentice-Hall, Englewood Cliffs, NJ, 1991. [6] D. Comer, D. Stevens. lnternetworking with tcr/ IP. Vol. Ill: Client-Server Progranu ling and Applications, PrenticeHall, Englewood Cliffs, NJ. 1993. [7] M. Milkr, Managing lmemetworks with SNMP, M & T Books, 1993. [8] A. Tanenbaum, Operating Systems - Design lind lmplementution, Prentice-Hall. Internal. Editions, Englewood Cliffs, NJ, 1987. [9] G. Vrecko, Control Node Unit 'Tecl",ic(;; .'I1m/lIa', Data book, Abit Corporation & MG-SOFT d.o.o., 1993. (10] G. Vrecko, A general microcomputer unit for distributed control of electrical devices over a communication network, Diploma work, Faculty of Technical Sciences, Mariboi, Slovenia, 1993 (in Slovene). [II] G. Vrecko, Z. Brezocnik and T. Kapus, A microcomputer unit for distributed control of systems in computer networks, Prac. Third Electrotechnical and Computer Science Conl ERK'94, Portoros, Slovenia, Vol. A, pp. 142-145, 1994 (in Slovene). [12] M. Vrecko, MONET - Ethernet M(1nif()ril/:~ System. Users manual, Abit Corporation, 1996, WEB URL: http:/ / www.mg-soft.sij.