Logistics Services and Intelligent Security Control for Transport Companies

The book "Cutting Edge Research in New Technologies" presents the contributions of some researchers in modern fields of technology, serving as a valuable tool for scientists, researchers, graduate students and professionals. The focus is on several aspects of designing and manufacturing, examining complex technical products and some aspects of the development and use of industrial and service automation. The book covered some topics as it follows: manufacturing, machining, textile industry, CAD/CAM/CAE systems, electronic circuits, control and automation, electric drives, artificial intelligence, fuzzy logic, vision systems, neural networks, intelligent systems, wireless sensor networks, environmental technology, logistic services, transportation, intelligent security, multimedia, modeling, simulation, video techniques, water plant technology, globalization and technology. This collection of articles offers information which responds to the general goal of technology - how to develop manufacturing systems, methods, algorithms, how to use devices, equipments, machines or tools in order to increase the quality of the products, the human comfort or security. following: Edge

D'Orazio et al. (D'Orazio et al., 2007) proposed a neural classifier to recognize the eyes in the image selecting two candidates regions that might contain the eyes by using iris geometrical information and symmetry. Smith et al. (Smith et al., 2003) presented a system to detect eye blinking and eye closure based on color statistics. Królak proposes a system which uses two active contours, one from each eye, for eye blink detection from previous eye tracking (Królak & Strumillo, 2008). Statistics show that between 10% and 20% of all the traffic accidents in Europe are due to drivers with a reduced vigilance level caused by fatigue (AWAKE Consortium, 2004). These figures show the importance that driver alertness monitoring applications can have to decrease the number of traffic accidents. Fatigue measurement is a difficult problem as there are few direct measures and most of them are measures of the outcomes of the fatigue rather than of fatigue itself. An important physiological measure that has been studied to detect fatigue is eye motion. Several eye motions were used to measure fatigue such as blink rate, blink duration, long closure rate, blink amplitude, saccade rate, and peak saccade velocity. PERCLOS measure is the percentage of eyelid closure over the time and reflects slow eyelid closures rather than blinks (Dinges & Grace, 1998). A PERCLOS drowsiness metric was established as the proportion of time in a minute that the eyes are at least 80 percent closed and it is a reliable and widely used driver performance and bio-behavioral measure (Wang et al., 2006).

System relevant features of the system
With the proposed system, transport companies can increase productivity of their drivers, optimize roadmaps, promote communication among all members of the company, and reduce the cost of transport operations. Each company has its own intranet, accessible via a corporate portal fully configurable by the user, and supported by Joomla!. Among the applications available on the intranet, in addition to the usual ones, there is a proprietary Enterprise Resources Planning (ERP), a Resources Optimization Module, and an Intelligent Security Control. The system minimizes the impact that the deployment, management, and maintenance of the central computer system have on the transport company. It outsources most of this workload to a third party logistics. Thus, the transport company can manage its resources more conveniently and transparently, eliminating the need for a large investment in computer equipment and the requirement to train or hire an expert operator. In turn, the company providing the service can meet the needs of multiple carriers with a lower overall cost, providing a specific "Know How" value to the quality of service. Each transport company may customize its contract selecting the services that it wants to outsource. Likewise, shippers may elect, at the instant of requesting the load, the associated services that they want to use. The installation of software on the transport company is not necessary because all management can be done from the telematics platform. In addition, the system is easily scalable, so the company can meet the progressive increase in demand. A resources optimization module makes route calculations take into account all data that can affect driving (works, accidents, planned events, weather, traffic ...), in addition to the points of distribution, number of available vehicles, etc.. Furthermore, regarding transport backbone, the system automatically selects the best suited truck-load-driver triad for a particular case.

www.intechopen.com
Cutting Edge Research in New Technologies

144
The system incorporates a new concept in fleet management systems: the driver's safety. Real-time monitoring of driver's face detects whether the driver's vigilance level drops below a certain threshold to control his level of fatigue. In the current system this task is performed on a laptop that sends data to the mobile terminal. The data are sent to the central control along with other information about the vehicle and freight, so that it may carry out monitoring and preventive control of the state of the driver. The vehicle on-board equipment incorporates a safety control system for the driver, which periodically sends data to the central control to prevent accidents due to fatigue or distraction of the driver. The rest of this chapter is organized as follows: the infrastructure of the proposed system is described in Section 2. The main modules included in the framework are described in Sections 3 to 6: kernel, Intelligent Security Control, Resources Optimization module, and onboard equipment.

System description
This section describes a complete multi-management system that incorporates advanced information technology and communications. The developed system is a telematics platform of logistics services, which allows companies to manage their mobile resources effectively, control them and get all the benefits of having timely and accessible information. The system is based on the use of computer science, and mobile and satellite telecommunications. These characteristics enable to convert a commercial vehicle fleet into a mobile intranet and to integrate mobile resources in the computing infrastructure of the company. The general scheme of the system in figure 1 shows the "classic" intranet of the company, the new Mobile Intranet, and different subsystems comprising the system. This scheme also shows the relationship between the different modules and the way information flows between them. Basically, the system consists of three major modules, namely Kernel, Intelligent Security Control, and Resources Optimization Module. The system is designed modularly to facilitate the addition or substitution of specific software modules responsible for carrying out system tasks. Thereby, the system is scalable and it is feasible to adapt its configuration to the specific requirements of the wide variety of transportation companies. The following sections describe the major elements of the proposed system, with special emphasis on the modules that distinguish our system from others of similar characteristics: the kernel, the Resources Optimization module, and the Intelligent Safety Control.

Kernel
In the developed system, the flow of information among the various components is carried out through the kernel, whose main functions are to provide access to databases for the different modules when they need it, and to establish a channel for information flow between them. This last feature allows the information contained in the databases to be centralized and managed by a single process (the kernel) that performs operations on data concurrently, thus ensuring data consistency and replica control. The system modules are connected in such a way that each module can be executed on separate machines connected to the machine running the kernel. The system tasks can either be both distributed in a network of computers or executed on a single machine. The Central Control is responsible for proper communication and proper transfer of information among the subsystems of the platform. The kernel exchanges information and controls the communications, the Web server, and the Data Acquisition and Management services. Since one of the roles played by this module is to carry the information flow among the rest of the modules of the system, sometimes its behavior will either be client or server. Therefore it has two channels for communication, one to serve information and other to receive it. The channel of communication between the modules of the system is established using sockets, a specific communication protocol, and client/server architecture.

Kernel development
The kernel of the system has been programmed completely in Java, using the NetBeans IDE suite. This kernel has been developed so that it is easily scalable and editable, due to a good structure and good use of object-oriented programming. Thus, adding new functionality (or changing an existing one) involves the modification of a few lines of code in one or a few files, each corresponding to a particular object. As regards access to databases, unnecessary resource consumption has been minimized. For this purpose, all information on the database for a particular company, which is stored in the system database, will be stored in a cache bin each time they are accessed for the first time and will remain in this bin until a certain time has elapsed since the last access. This way, multiple simultaneous queries from a client will only impact on the database system the first time they are accessed, avoiding redundant queries. To implement this feature, we have opted for the use of both threads running in parallel to the rest of the program, which does not increase the memory needed to run the program, and dynamic tables which allow a quick and easy access.

Communications
The main method of communication between the kernel and the outside is through XML messages, a procedure that is already being widely used in B2B communication. Java libraries and JAXB tools have been used to facilitate the handling of this format. These tools allow fitting up objects with XML messages. Thus, any addition or modification on the structure of the XML is very easy to implement, because it would be equivalent to including an additional variable in the class of the specified object. Figure 2 shows the diagram of communications among the kernel and the rest of the components of the system: internal modules, external modules, optimization module, and vehicle on-board terminal. The kernel maintains connections with databases permanently, as well as with clients who connect with it. Therefore, to avoid problems of persistence, a thread in parallel to the core is permanently executed. This thread is responsible for detecting when someone wants to exit the system, so that it is responsible for closing one by one all the connections opened at the same time, ensuring that the system is closed only when all the data that the system has to process are ready. A communication procedure based on XML messages has been developed so that external modules can communicate with the kernel. To achieve it, the kernel creates a thread that is permanently waiting for incoming connections. When a connection is detected, it is accepted and sent to a connection manager, which will create a new thread for the new connection. The kernel goes back to the listening mode while the new connection is processed. Then, the kernel processes the received XML message. To do this, the kernel has a "parser" or interpreter of XML messages, which transforms the received message in a series of particular objects, so that they can be accessed easily from any system method. However, these objects are encapsulated within a specific object for requests which is in charge of returning the fields requested by any part or function of the code so that if the format of XML messages or the format of communication are changed, only the inside of the objects, and not the rest of the system, has to be changed. Once the message has been interpreted, it is redirected to the internal module indicated in the header of the specific request, or to the link with an external module if necessary. These modules are responsible for generating a response based on the received information. For the answer, there is an object similar to the object used in request, which generates the same XML data from Java objects. Once the response is complete, it is returned to the kernel thread that was processing the connection, which is responsible for returning through the socket connection to the external module. After sending the message in XML, the kernel closes the connection to the module, and ends the thread that was processing. On the side of the client or external module, the system is similar: when a module requires certain information or needs to add or update fields in the database of a particular company, it generates a specific XML request, creates a connection to the Kernel, and sends the XML message. Subsequently, the module is waiting for a response and, once received, interprets or processed it, if necessary.

Communication between the kernel and the optimization module
Optimization module opens a TCP/IP socket server, which is listening to client connection requests. The kernel initiates communication through an authentication message when it requires a service of resource optimization. After a validation message from the server, the kernel generates a request message to calculate routes that are sent via socket to the optimization module. This message contains the source and destination of all cargo and vehicles involved in the process of optimization. It also indicates the identification of drivers available for each vehicle and the date and time of pickup/delivery of each load. When the optimization module receives the routing request message, it checks the format and content. If the validation is successful the application starts the processes of simplification, preoptimization, and tabu search with the received parameters. These processes are described in the section dedicated to the optimization of resources. Upon completion of these processes, the server generates a message containing the calculated route for each load, assigned vehicle and driver, as well as identifiers of the main crossing points (and the associated time) that are crossed by the vehicle between the source and destination. Message with the route and the transmission completion message are sent to the kernel, which terminates the communication after reporting the correct reception.

Communication between the kernel and the mobile terminal
This module implements the communications with the Mobile Intranet or GPRS network, consisting of all commercial vehicles equipped with a GPRS device. The network of mobile terminals (also called Mobile Intranet or Fleet Area Network) communicates with the company's kernel through two channels: the first, through the Internet, and the second through a multi-channel GPRS modem that is used to send data in real time to mobile terminals. The choice between the two channels or a hybrid solution depends largely on the comparison of connection and installation costs. The first channel is used for the regular transmission of data from the vehicle to the kernel. To achieve it, a plug-in is installed on the PDA, which allows establishing a fast and encrypted connection with the Web. When the connection with the PDA is established, the XML message is sent periodically throughout the mobile service provider to the system's Web site. Then the kernel sends this information to the corresponding module which will process the service request. The second channel communicates with the GPRS modem system, through the Mobile network operator. Its main task is to send messages to modify or update data, and above all, emergency messages, although it can also be used for the transmission of positional information when the other channel is not available.

Communication between the vehicle on-board terminal and the intelligent security control
Currently the intelligent security control is implemented on a laptop that communicates with the mobile terminal through a client socket that connects to the server socket of the mobile terminal when it is ready to send information. The application communicates with the server core using WSDL (Web Services Description Language) language that describes the public interface to the Web service, i.e., the methods that the device application can use. It is based on XML and describes the form of communication, i.e., the protocol requirements and the message formats required to interact with the services listed in its catalogue. The client program (the application) connects to this Web service and reads the WSDL to know what functions are available on the server and the class of data that can exchange between them. WSDL has been used in combination with SOAP 1.1, XML Schema, and HTTP GET/POST. The client program connects to the Web service using the SOAP (Simple Object Access Protocol) protocol to make the call to each of the listed functions. Special data types are included in the XML Schema format. At the present time, a client-server connection based on bluetooth is being developed. This connection will replace the current connection to prevent the driver from having to manually connect on-board mobile devices. This bluetooth connection also allows a much easier migration when the intelligent control of security is integrated into the on-board computer, or into a specific device.

ERP module
The main features of the ERP module are: It allows the user to enter both deliveries (road map) and destinations of a vehicle and to specify the information associated with each or them (customer, sales order, invoice, freight or product description, name of driver, etc...). These schedules (sequences of deliveries) can be displayed to control their specific performance. Client management allows the user both to geo-reference and to enter information from their clients, taking into account the basis of a Geographical Information System (GIS). Georeferences can be structured according to different categories and levels. It has ease of search and updates the entered information (addresses, categories, etc.).
The stored and processed information (by Individual Taxpayer Identification Number (ITIN), truck code, etc.) related to events associated with the vehicles and their planning (e.g. location, mean speed, vehicles stops, deviations from the planned route, visiting customers checks, etc.) is used to measure performance and draw conclusions that will improve the overall management. Planning and vehicle fleet operations can be managed and displayed by an on-line dynamic control: location of customers and vehicles, pending and completed delivery routes, checkpoints passing, speed and dwell time of vehicles, state of driver fatigue, and other data that the client can set as part of their own particular configuration.

Access to the system
The system can define different user roles (administrator, operator, customer, driver), and control access levels to the various tools and information services. The customer (freight forwarder) accesses the system through the web site of the company. Once the access has been validated, the freight forwarder has a menu with the basic freight hiring service, in addition to those services that he wants to hire for a specific load. For example, he can request online information about the status of his freight. The system generates a web page with the information about the freight status, the estimated time of arrival, as well as a map with the planned route, current route, and the one followed by the vehicle. The fleet operator accesses the system through the web site of the company. Only register operators can access the system, and different operators can have different privileges. According to those privileges, an operator can access the data from all currently active services, accept orders from new costumers, request locations of their trucks, etc. The drivers have a mobile terminal that establishes a bi-directional communication via GPRS to the central system. On the one hand, the system allows updating or modifying the geographic data through the collection of traffic data sent by the vehicles, as well as the RDS-TMC information provided by the Traffic Department. Those data together with the indices of driver fatigue are sent periodically to the central system. On the other hand, the central system can send alerts, incidents, new assignments, or routes to the mobile terminal.

System interface
In the latest version of the developed system, all the users access the system through the website of the company. Once the company has hired the provider services, the system generates a Web portal based on the CMS Joomla! This configuration allows the company to customize its website, offering information that it considers useful, and in turn, managing registration and access to the portal. This portal is also used as an access point for both fleet operators and potential customers. This configuration has another advantage: the carrier does not need to install anything on their computers. Even the resources of the customized web portal can be hosted on a server of the provider. The interface is permanently connected with the kernel located in the service provider through the Internet. This will establish a constant flow of information, since the nucleus is responsible for transmitting requests, from both operators and customers, to the central system, and in the opposite direction, receives and presents the responses generated by the kernel to such requests.

Agents
Potential agents that can use this interface can be classified as: the system administrator, webmaster of the company, traffic agent of the company (or fleet operator), and freight forwarders. Here are the characteristics associated with each one. The system administrator is responsible for managing the hiring and maintenance of administrative data and resources hired by each company. For these tasks the administrator uses the provider's own web portal, which can connect directly to the kernel just as the rest of the portal. This agent is the only one who has access to the administrative database of the companies. The webmaster manages the portal web site of the company. He is responsible for maintaining the data of registered users and for updating commercial content that the company can offer its clients through the portal. Another function of the webmaster is to register the traffic agents of the company, and validate the users who register. He doesn't have access to the central system. This role can be performed by an employee of the company. Otherwise this provision can be included in the portfolio of services under contract with the supplier if the company prefers it. Anyway, it is not necessary for the company to install anything on its computers. The traffic agents are directly recorded by the web administrator of the company. This register allows them to access all the services hired by the company. Obviously, the menu at the interface of the traffic agent differs substantially from the Web administrator menu: one manages the portal Joomla! and the other manages the fleet. Once the company has registered an agent, he can access the system and have all the information from the business and take action on it. He can access the data of all the currently active services, accept the hiring of new clients, request location and status of their trucks, send instructions to the driver to change the service, and so on. Freight forwarders can register through the website of the company, or can contact the company to apply for registration as a customer. In the latter case, the webmaster makes the registration on the website and the traffic agent recorded them in the company database. Obviously, each company has its own database of customers. The administrative databases of the companies are independent, which ensures the confidentiality of the data. Once registered, the client can hire the services of the company through the Internet. The client can access the company Web site, log into his account and through a form, and enter the necessary data about the load to request a transport service. If the load is accepted, data is recorded in the corresponding database. Once the loads are hired, the customer can request information about the state of their loads. The system responds, through the Web connection, by sending the next information: a map of the location of the truck with its load and an estimated time of arrival.

Interface description
The system's web interface has been developed entirely in PHP and HTML, and is ready to function as an integrated component within the content management system "Joomla". However, it has chosen to give greater flexibility to the interface, so the business logic of the interface can run on any web server with PHP support. As the kernel, the interface has been developed with an object-oriented architecture, so you can make changes or include new features without changing any code. Thus, there are objects only responsible for generating requests and processing responses, others that are in charge of interpreting the parameters of an answer, and another, more complex, which is responsible for displaying all the necessary information in HTML format. The design has been chosen to look simple but effective, based on intensive use of tables (playing with the sizes and edges), and the help of some JavaScript code to give certain dynamism to the content. Due to the intensive use of tables, we have developed from scratch a module (object) that is responsible for creating virtual tables in the system memory, with a large variety of options and features, so that the code for the object generator of HTML is more understandable and scalable. Subsequently, a function of this module encrypts all the information in HTML code which will be integrated into the web interface. This module also allows nesting tables and inserting a table within another without being in HTML. Thus, modifying a particular field is much easier and more intuitive than if you modify the HTML directly. The external view of the interface (what the user sees) is similar to most of the fleet management systems available, so this chapter does not include screenshots.

Intelligent security control module: Driver alertness monitoring
This module is aimed to monitor the driver alertness level of each fleet vehicle with a view to both sending the fatigue level to the central control and preventing the driver when the alertness level is too reduced so that driving can be considered dangerous. We developed a robust real-time module to detect the eye state of the driver with a consumer-grade computer, an inexpensive Universal Serial Bus camera, and passive illumination. While previous approaches have proposed many different methods and features to fulfill eye and eyelid closure detection, our module focuses on the calculation of multiple features of different nature in the eye region to distinguish three eye states, open, nearly close, and close, in the eye regions. The use of three eye states is necessary to calculate PERCLOS as in (Dinges & Grace, 1998) accurately. We accomplished the discrimination among these states of a non-rigid object with high variability such as the eye with a multiple-feature scheme. The module is based on Multi-Layer Perceptron classifiers, which are used to measure PERCLOS, runs at 40 fps and achieved an overall accuracy of 97% with videos with different users, environments, and illumination.

Development of the driver alertness monitoring module
We aimed to monitor the driver alertness with the PERCLOS measure. PERCLOS is meaningful in highway driving when the driver face is mainly in frontal position with respect to a camera placed on the car dashboard and there is low head motion. For the face detection, we use the frontal face detector based on the AdaBoost algorithm and with Haarlike features available in the framework of the Intel Open Source Computer Vision Library (OpenCV, 2009). This detector has a great performance with frontal and near frontal faces. Rectangular pair of eyes region location is determined using face and head anthropometry measures from the output given by the face detection. As the face detection is mainly based on the eyes, they can be accurately located. Assuming that eyelid closure is simultaneous in both eyes, the eye state has to be determined in each frame of a video sequence to compute the PERCLOS measure. Therefore, we had to discriminate among open and close eye state and also the nearly close state, which is characteristic of a high level of drowsiness of the driver. In this state, the proportion of visible iris is below 20% of its total height. Due to the large variability of the eye appearance and dynamics, our approach was not to extract an individual feature or a small set of features as individual features are influenced by the fact that a feature with a very wide class of invariance loses the power to discriminate among other differences. On the contrary, we have extracted many features of different nature to achieve robustness to illumination, presence or absence of structural components such as glasses, and facial expression. The extracted features were: 1-D grayscale histograms, 2-D color histograms, horizontal and vertical projections, and the entire rectangular eye images. Regarding grayscale images, an eye can be characterized by the intensity of two regions, one corresponds to the iris and the other to the sclera so 1-D grayscale histograms are extracted. 2-D histograms of the chromaticity components (HS) of the HSV color space were extracted to discriminate between an open and a close eye with some illumination invariance as skin colors have a certain invariance regarding chromaticity components (Sigal et al., 2004). Horizontal and vertical projection functions of a grayscale image I(x,y) in intervals [y1,y2] and [x1,x2] are expressed in Eq. (1) and (2), respectively. Zhou & Geng (Zhou & Geng, 2004) proposed the horizontal and vertical generalized projection functions. We calculated the four mentioned projection functions.
(2) Once we have the information of an eye image captured in a feature set, there are two possibilities from endowing them with meaning: make a unilateral interpretation from the feature set or compare the feature set with some elements on the basis of a similarity function. As proposed in (Bradski, 1998), the complexity of the eye detection problem makes it necessary the use of a similarity function to achieve the desired accuracy in analyzing eyelid closure with non-strictly frontal face, in motion, and with illumination changes. The elements to compare the feature set of an eye image are the templates of open eye, nearly close eye and close eye.

Similarity functions
With the information obtained from the eye regions, a big number of similarity measures between the eye regions and the three templates were extracted. Our approach is to compute a set of different similarity measures so that the best measures be selected later. First, we obtained four histogram-based similarity measures: correlation, χ 2 , intersection and Bhattacharyya distance. The following four template matching methods to measure the similarity are applied to the entire eye regions and the projection functions of the regions: correlation matching, correlation coefficient matching, and the normalized versions of the two matching methods. Unlike the histogram-based measures, these methods compute the spatial distribution of pixels. The correlation matching method multiplicatively matches the template T against the image I to obtain the matching result. The correlation coefficient matching method matches a template relative to its mean against the image relative to its mean. The normalized version of the correlation and the correlation coefficient matching methods are obtained dividing them by the same normalization coefficient. They are useful as they can help reduce the effects of lighting differences between the template and the image. Each similarity measure between an eye region and a template represents an eye region feature.

Feature selection and classifiers
After computing a big number of features, dimensionality reduction is necessary. Many features are not suitable to classify eye images because noisy and redundant inputs can have a bad influence on the classification performance (Devijver & Kittler, 1982). Dimensionality reduction approaches can be classified in feature extraction and feature selection algorithms. Unlike feature extraction, feature selection allows to make inferences on how input variables affect the model results. We have compared two selection algorithms: the J 5 (ξ) criterion (Devijver & Kittler, 1982) and the SFS (sequential forward selection) (Jain & Duin, 2000). We used classifiers widely used in data classification and pattern recognition: MLP. MLP is a type of Artificial Neural Network (ANN). ANNs, which are inspired by biological neural networks, are composed of neural-like units connected together through input and output paths which have adjustable weights (Haykin, 2008). The MLP is an ANN which has been very successful in a variety of applications, producing results that are at least competitive and often exceed other existing approaches.

Driver alertness monitoring module performance
We selected two MLP-based classifiers from many experiments for the eye state monitoring module: one for the pair of eyes and the other for the individual eyes. We used 12 videos to test the module: six videos from the ZJU Eyeblink database and six videos from our private database, all with 320240 pixels, with a face in frontal or near frontal position and a wide range of conditions: translation and scale changes, some people wear glasses and different illumination conditions. Two videos from our private database were recorded with a camera on the dashboard of a car while a user is driving in real conditions. The average overall accuracy is 97% for the 12 videos. Video frames were different from the training images, although some people in the videos from our private database, apart from the videos recorded inside a car, were included in the training set. The system performance is also high in videos in which the people do not appear in the training set. In-car videos have a lower performance due to the poor illumination conditions, unlike the rest of the videos, which are indoor videos with better illumination conditions. In spite of that, overall accuracy percentages of the in-car videos allow a reliable PERCLOS computation to monitor the driver alertness because most of the errors are produced when the eyes are in a transition state, in which the eyes are open but not completely. Processing times were taken with an Intel Core 2 Duo processor at 3 GHz and 4 GB RAM, with the software implemented in Visual C++. Each frame takes 25ms on average, out of which 14 ms are taken for the face detection and the remaining time is mainly devoted to the eye region feature calculation and eye state classification. AdaBoost-based face detection is applied to image subwindows varying in position and size from a minimum size. We adapted this minimum size depending on the face size in the previous frame, with width and height two-thirds the face width and height in the previous frame. These processing times give rise to a frame rate of 40 frames per second (fps) so that real-time driver vigilance monitoring is achieved. Frame rate was limited by the 30 fps given by the two cameras used in the experiments: Logitech Quick Cam Zoom and Philips SPC315NC. Fig. 3. Output of the driver alertness monitoring system with two video sequences. Figure 3 shows frames of two video sequences in real driving conditions. Face detection and eye region location are drawn in the frames together with the output of our eye state monitoring module. Our module is used to monitor the driver alertness through not only the PERCLOS measure but also the non-detection of the face or the close eye state detection in a series of consecutive frames. There is one threshold for each of the three measures: TH PERCLOS is the maximum value of PERCLOS allowed for secure driving; TH face is the maximum time without detecting the face in consecutive frames allowed for secure driving; TH eyes is the maximum time detecting close eye state in consecutive frames for secure driving. These thresholds can be adapted to each driver and the level of alertness required for driving (high, medium, or low). At the time when any threshold value is overcome, alarm state will be triggered. The driver will have to react and return to a secure driving state to abandon the alarm state.

Resources optimization
In a transport company the drivers' management strategy is a fundamental aspect to achieve an optimal allocation of resources. The factors that influence this strategy are diverse, and the most relevant are: the limitation of the maximum driving time imposed by law for drivers, the possibility of incorporating two or more drivers within the same vehicle, the availability of drivers which restricts the number of vehicles that can be on the road, and the own cost of hiring or maintenance of drivers. The information on loads and trucks was used in an early version of this module. In the current version, the information about the company's drivers is incorporated. This new addition resulted in a very significant decrease in the performance of the previous optimization module. This module was implemented using evolutionary programming, and these changes made slower genetic operators be slower. On the other hand, the increase in the number of parameters leads to a more complex evaluation function. This fact led to the need to design and implement a new algorithm that could adapt to new conditions, while maintaining a high level of performance. The main factor that determines the choice of the most appropriate methodology to solve the problem is the very large number of possible cases that need to be evaluated during the process of resource allocation when the management of drivers on the transport routes is included. This factor has a direct impact on the processing time of the algorithm, which will increase with the size of the company's fleet. In order to ensure a rapid implementation, the resolution is divided into two phases: problem simplification and resource allocation optimization. Simplification process consists in considering only the routes involving a shorter route between trucks and cargo, leaving out the rest of sections of the road network (see figure 4). The algorithm takes into account the updated information about the road status, the traffic density, and the distance between the origin point and target point. These routes are classified into three categories: routes that link the origin with the destination of each load, routes that lead the trucks to each load, and routes from the target of each load to the origin of other loads or to the current location of the transport vehicles. Achieving the best route in each of these categories refers to a problem of solving the Shortest Path Problem (SPP) (Helgason et al., 1993). The method chosen for implementation is Dijkstra's algorithm with double buckets (Zhan & Noon, 1996) because its proven speed and its perfect adaptation to the class of graph generated by real networks of roads, characterized by their low level of connectivity. This solution must also fulfill that the selected vehicle is suitable for transporting the assigned load and that the delivery time does not exceed the specified delivery time. There are several algorithms that allow to find this solution, and which provide an acceptable computing time. For the proposed system, we have chosen the TabuSearch algorithm (Glover & Laguna, 1997). TabuSearch is a mathematical optimization method, which belongs to the class of trajectory based techniques. TabuSearch enhances the performance of a local search method by using memory structures that describe the visited solutions: once a potential solution has been determined, it is marked as "taboo" so that the algorithm does not visit that possibility repeatedly. Its most important feature is the fast convergence when the solution is approaching to the optimal solution. Its computational cost is low when assessing very few solutions in comparison with other methods; generally it does not exceed 5 or 10%. The fact that the found solution may not be the best, but a local maximum, constitutes one of its disadvantages. However, the application of different techniques can reduce this possibility to null or very small margins. Depth-First Search & Breadth-First Search algorithms (Cormen et al., 2009) were also tested. These methods were dismissed due to its low performance in problems with a very large number of possible solutions. The response time of genetic algorithms and evolutionary programming does not grow exponentially when the data of the problem increase as it happens with searches in breadth and depth. However, its performance drops considerably when the used genetic operators execution slows down and when the degree of the evaluation function increases. The algorithms we have developed for the stages of simplification and optimization of resources are integrated into the system through the kernel. The kernel is responsible for providing both the communication with the database that contains information about the company's resources and communication with other components of the system. The performance tests were performed on a PC equipped with processor Intel Pentium 4 2.5 GHz with a Windows XP operating system and 256 MB of RAM. The Geographic information used in the tests includes the main towns and roads of the Spanish road network, which is a graph with 4574 arcs and 3636 nodes. The evaluation of the simplification process implemented using Dijkstra's algorithm with double buckets was carried out considering routes from 100 origin nodes to a set of 300 target nodes, both chosen randomly. This result applied to a transportation company with a fleet of 50 trucks and 200 hired loads, allows calculating optimal routes in 11.5 seconds. In the light of these results it is clear that Dijkstra's algorithm with double buckets is a valid option for this process. To achieve an effective implementation of TabuSearch for the resources allocation to the previously computed optimal routes, the following aspects were considered during its development:


Each solution consists of a set of routes. A vehicle, a driver, and a series of charges are allocated to each route. The variable to optimize is the total travel time for all the routes.  Criteria for validation of routes are fixed. These criteria are based on the number of transported cargo, on the compliance with delivery times, and on the restrictions arising from the drivers and vehicles.  Identification of neighboring solutions is determined by a double replacement of vehicles between routes. This procedure maintains a reduced range of tested solutions that ensures the achievement of the absolute maximum in the 100% of the tested cases.  The starting point to begin the optimization process is to assign to each load the nearest vehicle. This is possible thanks to the ordered list of closest vehicles prepared by Dijkstra's algorithm in the simplification phase. This way the algorithm is considerably faster because it is highly likely that the initial solution is already very close to the optimum. In fact, some vehicles are already definitively assigned to a load in this point. The tests performed in the same conditions and with the same cartographic information that the tests performed in the simplification process, produced times of execution of the algorithm below 0.5 seconds for the specific case of 15 vehicles, 15 drivers, and 10 loads.

On-board equipment
The on-board equipment consists of two devices: intelligent security control and fleet management module. On the one hand, the security module performs a monitoring in real time of the driver fatigue status, critical to workers whose working life is spent on the road. It is currently implemented on a laptop. On the other hand, drivers have a mobile terminal that graphically shows both the position of the vehicle and the calculated route. This terminal receives information about the state of the driver from the laptop and sends it to the kernel along with information about the position of the vehicle. The following sections describe the main features of the mobile terminal application.

Mobile terminal features
Each mobile terminal includes a plug-in that enables bidirectional communication between the vehicle and the base via GPRS, and obtains the geographical position of the vehicle by reading GPS signals. It also has a graphical interface that allows the driver to see the route to follow and receive update messages or warnings about incidents on the road or load, or in situations where the vehicle deviates unusually from the established route. Each driver has a unique identifier (own code of the mobile device). When a driver runs the application on his mobile device, the application connects to the kernel to authenticate him. If authentication is successful, it returns the assigned route o routes. For each destination, the driver is provided with the best route to follow, previously calculated in the corresponding module, as well as detailed data for each delivery/pickup point (cargo, address, city, telephone contact, etc.). The application allows real-time tracking of each vehicle by sending the coordinates of the current position to the database system. When the vehicle arrives at a destination, the driver can record the date and time of arrival at the point of delivery, pick up the recipient's signature and record the cause in the event that delivery has not been possible. The driver can use the application to inform the system about incidents (accidents, breakdowns, traffic jams) produced along the route. Besides, the driver can access the company intranet for information or to report something, or he can communicate with the kernel to request the calculation or recalculation of a route. The application uses Google Maps for showing the optimal routes. Because of its low usage of resources, Google Maps does not require much space in the device memory, and the driver can display the full path to follow. The following section describes this feature in more detail.

Driver Interface
The most important function of the driver interface is to show the physical maps for each of optimal route, and inform the user about the points he has to reach along his route. To achieve this, it was initially decided to use the Google Maps API, which allows developers to integrate maps free in any Web application with JavaScript.   6. Integration of Google Maps with route data. By clicking on each of the marks, the application shows more detailed information. Figure 5 shows the result of integration of the Google Static Maps API on the PDA. It shows this type of map for each pair of destinations associated with each driver. In this map the driver can find origin marks, target marks, and the optimal route generated by the optimization module. All these data are sent in the URL of the HTTP request. Later this solution was found to be inadequate, since, being a static image, the user cannot zoom in to view the streets to cross, for example. Moreover, if it is not possible to write any "window of information" or any mark, the driver cannot know the geographic data of the intermediate points of the route. For this reason we chose the following solution, which is more appropriate. Google Maps provides an executable file (compatible with Windows Mobile 5.0) that can be downloaded and installed on any mobile device. Having completed this step, we designed a C# application that runs Google Maps in the mobile terminal and loads the file that contains information about marks and intermediate points in the optimal routes. The driver can perform zooms and any movement on the loaded maps and can access all the information by clicking on each map element (see figure 6). The files that are loaded are described in KML (Keyhole Markup Language) language. KML is XML-based and is used to represent geographic data in 3D. It was developed especially for Google Earth, though their version 2.0 is also supported by Google Maps. Each file specifies a title, a description of the place to represent, its coordinates (latitude, longitude, and altitude if desired) and some additional information.

Conclusions
The proposed system is not only directly relevant in the automation of the processes involved in managing commercial fleets, but it also presents a business opportunity to large communications companies. This whole project results in a strategic weapon for companies, which provides management services and an essential tool for transport companies, strengthens their market position, and makes them more competitive and efficient in their processes. The main innovations of the proposed system are focused on the design of the platform of logistics services, the optimization of the process of allocation of resources and routes, and the monitoring of the physical condition of the driver in real time. We have successfully implemented the core modules of the multi-manager platform. We have also established a robust and scalable communications protocol based on XML message exchange, and have designed and implemented a database system, using the MySQL engine. The developed kernel is fully modular, well-structured, and very stable against bugs, doing a high control of exceptions to prevent it from collapsing in anomalous situations. Moreover, due to the use of multiple threads, we have achieved a more flexible kernel that makes a better use of system resources, ensures greater integrity of concurrent access to the database, and minimizes the accesses to expedite the top requests. The Web interface has been designed through sober but functional design patterns, and shows a fairly accessible and professional look. In addition, we have implemented all sections of the interface with the same physical appearance to make it easier to use, and to allow their integration into the other components of Joomla! to be as transparent as possible. With regard to the communication protocol, we have chosen an implementation based on XML messages. This option will have the greatest future growth and is the most understandable by humans. This way, it is easier to understand the operation of the communications protocol and add or modify some aspect to this protocol. It is not necessary to generate new code in the system modules to interpret and generate these messages, since there are XML parsers for the majority of the programming languages. The module of optimization of resources allows optimizing the allocation of loads, vehicles, and drivers, and the dynamic and adaptive calculation of distribution routes taking into account the special incidents along the route that may influence the traffic. To achieve greater precision in the route optimization we have to feed the module, in addition to the data supplied by the traffic authorities, with data submitted by the vehicles of the companies that are using this platform. Unfortunately, we cannot have this valuable information until the system is in production. On the other hand, the incorporation of faster processors in the future will allow processing an increasing volume of traffic and cartographic data and calculating and updating the path in real time with more precision. The system includes a module to monitor the driver alertness level of each fleet vehicle. Although the module runs in a standard laptop computer and a Universal Serial Bus camera, a PDA cannot be used to run it in real time. Experimental results showed the robustness of the module to changes of driver appearance, illumination, and environment. The module can be used to compute the PERCLOS measure, which showed the clearest relation with driver performance compared to a number of other potential drowsiness detection devices in literature. Besides the PERCLOS measure, the module obtains the consecutive time of non-face and close eye state detection for robust monitoring driver vigilance. The massive use of such in-car security modules would have a big impact on the number of traffic accidents, decreasing their huge economical and personal cost. Finally, the integration of all these components has been successful and has generated a stable and robust final system as laboratory simulations and field tests have shown.

Acknowledgment
This work has been partially supported by the Goverment of Castilla y León (Spain), under the project VA171A11-2.