Traveling Linux: An Implementation Experience for Unattended Management Applications
The precise knowledge of the patronage mobility features is not enough to solve every management problem of a bus company. In this industry employees are spread throughout the land and can be reached for service instructions only at particular times and at precise network points. Thus, programming the employee and bus schedule ahead of time is important, but does not allow for time lost in the work organization due to network problems, accidents, organizational difficulties or unexpected demand changes.
Therefore, we did a survey on the checking methods and technologies used in other countries. In general, these systems have been applied to the urban services of mid-sized metropolitan areas. The check service ends at the border of the suburbs, mostly because of the high investment costs needed for the radio transmission equipment. Architectures are normally based on these general features:
Almost all check intelligence to a central point that is able to process a great quantity of data (in general, computers with real-time, special operation systems);
Availability of a radio network with a great number of transmission channels and widespread cover, using a polling transmission method with every vehicle questioned to determine its position at very short time intervals (in general, less than a minute);
In case of limited radio cover, integration with infrared active captor systems or with passive markers to reach vehicles or to allow them to correct their position;
The intelligence on-board is collected by devices with industrial electronics features and proprietary technology based on a moderate capacity CPU.
In recent years, the check systems described above have made an evolutionary jump following the availability of a location system, based on the GPS technology, in the civil market. This system, although limited in very crowded areas, simplifies the vehicle location electronic systems with a noticeable increase in accuracy.
Based on the above experiences, the system project features were defined for the intercity and urban services in the Provincia di Bolzano, which operate under the following conditions:
The control network covers a length of 2300 km, of which more than three quarters is in an alpine area;
The regulation and structural situation existing in the national spread of radio frequencies does not allow a sufficient number of channels to construct a polling system for the land in question;
The existence of several different companies, with different organizational structures, means there must be control models with very simple features, but always consistent with a standard system management; therefore, the overall system functionality can be linked to a single control center that can define all relevant vehicles and send out operation instructions;
The existence of the magnetic payment system at its current development level requires its integration inside a single on-board system that will allow more developments and implementations as needed.
In this case, it seemed necessary to set up on every vehicle a knot of the operation system that could develop, in strict autonomy, the production management functions, while maintaining the overall integrity of the system and requiring the least amount of resource spending. Functions had to be modular—that is, put into action according to the needs of the company that owns the vehicle and provides the service. Every vehicle must be able to determine its own position, time and program consistency, without requiring a constant link between vehicle and operation center.
Each working program change that could be foreseen for a vehicle and its operator had to be described with a minimum of verbal communication, using the same standards as the instructions of the central information system of the company. The only solution that fulfills these requirements is a multitasking operational environment that can be integrated with the company information system (based on DG/UX 5.4.3, the implementation of Data General CO of Sys V rel.4). The purchase of an Intel-based commercial system for more than 400 vehicles would require license investments of more than a hundred million lira.
Moreover, the need for non-standard features in the trade systems (particularly terminal use, watchdog management and advanced power management) might make it necessary to intervene at a system level, with all the possible troubles between the software distributor (Italian) and the owner (American).
In this framework, Linux is the only operating system that works for our project. The features we considered in Linux's favor are as follows:
System steadiness. With the 1.2.13 (and better in the stable 2.0) the machine average uptime is much more than that for any of the other widely circulating Unix systems for the Intel platform that we tested. (And we tested almost all of them.)
Source code availability and quality. Many of our special needs are already contained in the development version (i.e., power management, watchdog, networking on radio net, etc.). The others will be met by either modifying the source ourselves or through cooperation with Linux developers.
Our management applications were born in a Unix environment. From 1980 until today, we had to face porting both to different architectures and to different systems (Ultrix, BSD, SCO, Interactive, DG/UX). The porting to Linux was the easiest and the most linear.
Linux is free. This was the most basic reason that helped us to persuade our management that Linux was the system to use.
We finished the setting up phase of the automatic vehicle location system in July, 1996. Following a European call for bids, Data General (Westboro, MA) was selected as supplier for the on-board PCs. The technical specification for the data transmission system had to be integrated into the already existing radio network.
Each vehicle's equipment is composed of a 486/100MHz PC, with 16MB of RAM, a 540MB hard disk, 10 RS232/422 serial ports, a SCSI controller and a type III PCMCIIA. The same PC case (140 mm x 140 mm x 158 mm) also contains a GPS Trimble differential system and an intelligent management unit that allows programmed system ignition, environmental functional parameter control and battery backup functions.
The systems were tested for very hard environmental conditions, since they must function in temperature between -20 to +50 Celsius degrees, and be shock resistant following military specifications (MIL-SPEC).
The PCs were linked with the current on-board terminals used for payment system management (obliterators and issue console), the communication equipment (radio or GSM, Global System for Mobile communications) and special public information panels.
Our current operating system is Linux 2.0.25.
Maurizio Cachia lives in a little village in the Dolomiti Alps with his wife and a funny golden retriever named Lu. He has worked since 1980 as a system analyst in the Unix environment for the public transport companies. In 1984 he became the Technical Manager of the Integrated Information System of SAD in Bolzano. He can be reached by e-mail at firstname.lastname@example.org.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide