Several regions were used for the testing of iVCAMS3. These regions included Calgary, Edmonton, Fort Lauderdale (Florida), Phoenix (Arizona) and a region covering Montreal and the New England region of the USA. The detailed street network of Calgary, Edmonton and Florida as well as a major road and highway network of North America were used. Up-to-date street network data sets of Calgary, Edmonton and Florida are available from sources such as Statistics Canada and the Florida government. These data sets, stored in the ESRI Shape format, offer extremely high levels of detail and even included minor side streets and alleyways. However, finding detailed road data sets of North America proved to be a much greater challenge. Ultimately, separate highway datasets for Canada, the United States and Mexico obtained from a variety of sources had to be combined together to form a single North American dataset and only has highways and major roads. Microsoft MapPoint was used to provide the detailed street network of all the testing regions in raster form.
For the iVCAMS3 implementation, only one computer was used as the Office domain server. This resulted in MAMSDev being used in its Client/Server form with all of its logic and modules running on a single server. The server consisted of dual 500 MHz Pentium III Xeons with 1 GB of memory and running the Microsoft Windows NT 4.0 Server operating system. Asset data, sensor configurations and other related information was stored into Microsoft Access databases. Apache Tomcat 5.0 was used as the Java Server Engine for handling the JSP and Servlet requests and also as the web server.
The next two figures show the realized implementation of the theoretical system displayed in Figure 5.2. In Figure 6.1, the architecture of iVCAMS3 when used with vector based maps from ESRI Shape files is displayed, while Figure 6.2 shows the architecture for when raster based maps from Microsoft MapPoint is used.
Figure 6.1: iVCAMS3 Architecture (Vector Maps)
The Web Client as developed for iVCAMS3 was tested on various desktops and laptops. Since the most intensive computing operations are done at the server-side, the Web Client’s processor and memory requirements are not high. The Web Client is designed for a display size of 1024 x 768 pixels in dimension or higher. This minimum display size is necessary in order to show all the information and available tools. Moreover, this resolution is commonly found on laptops. The testing platforms consisted of a Sony Vaio Z505 laptop equipped with a Pentium III 750 MHz processor and several desktop computers of various speeds.
Through testing, it was determined that the configuration storage scheme most suitable for a wide range of data sets was a three-layer pyramid. The bottom layer was divided into 31 x 31 cells, the middle layer was divided into 2 x 2 and the top layer has only one cell. This particular configuration results in cells that overlap each other, so that no cell of one layer shares the same border edge as a cell in a lower or upper layer. This overlapping reduces the likelihood of a small vector feature that straddles the border of a cell in multiple layers. This configuration resulted in a balanced storage of the vector data, with each cell having similar numbers of features thus promoting quick and consistent response times for queries.
The CSI Asset-Link sensor was selected as the sensor to be placed onboard the vehicles. It can completely act as the data acquisition component of a MAM and has two-way capabilities making it suitable for use with iVCAMS3. Because of its small size, the Asset-Link sensors can be discretely hidden into vehicles, making it an effective alarm and monitoring system. Its low power consumption ensures that it does not detrimentally
affect the performance or usability of a monitored asset, even if the asset is put into storage or is inactive for weeks or months.
Despite the data limitations of MicroBurst, it is still possible to encode useful information such as location, speeds, heading, battery voltage and engine status into one or several number strings. The sensor can also send multiple types of messages. This can increase the number of attributes that can be monitored as each message type can contain unique information. Industrial partners provided the configuration setting of the CSI Asset-Link sensors, which were also used to configure the database management component of the Data Module. The configured capabilities of the sensor were also needed to customize the Application Module to provide the necessary tools to access the available asset data and control the asset. The information that the sensor could send back were:
Asset locations in the form of latitude and longitude. Asset speed, heading and odometer readings.
Alerts for low battery voltage, emergencies and speed violations. Acknowledgements to pages and commands.
The sensor accepted the following commands: Request for current position.
Start continuous tracking and automatically send back its position every 5 minutes for one hour.
Unlock the door of the asset connected to the sensor.
Enable or disable a 75-mile per hour speed limit. When the speed limit is enabled, the sensor will automatically send a speed violation alert back to the server.