Communication Module

The Communication Module contains the functionality to make and maintain the connections to assets. The current implementation of the Communication Module has the capability to interact with CSI Asset-Link sensors using the Aeris.Net MicroBurst wireless data service. These two technologies were chosen because they best meet the specifications given by industry partners. The Communication Module is part of the Platform Layer; there is no need for developers to modify the source code. The only configuration required is to input settings regarding the IP address of the Aeris.Net servers and account settings to login to Aeris.Net’s servers. Table 5.1 summarizes the

capabilities of the Communication Module.

Table 5.1: Communication Module Capabilities

Features Description Connecting, authentication

and reconnection

Makes initial connection with Aeris.Net servers, provides the proper authentication and automatically reconnects if interruptions occur. Automatic Message Response Responds to any inquiries sent by the Aeris.Net

server and issues regular messages to the Aeris.Net server to maintain connection.

Message Decoding/Encoding Aeris.Net message packets are encoded in a binary form; the Module decodes the packet back into the original human-readable form. Messages to be sent to the Aeris.Net server are also encoded into the necessary binary form.

The Communication Module connects to the servers at Aeris.Net’s central hub using the Internet with network socket connections. Two connections are made; one connection is to the Aeris.Net Data (DS) Server; this server relays messages sent from a remote Microburst-enabled sensor back to the Office. The other connection is with the Aeris.Net Page (AS) Server; the AS Server relays the commands or pages sent by users to the sensors and assets. The Java implementation of a network socket is “blocking”, or in other words, stop all activity in the thread or process that the socket is running in while waits for new data to be sent from the Aeris.Net server. This feature helps reduce processor utilization since a non-blocking implementation would require a continuous loop to constantly check on the state of the socket and determine if any new data has been

received. This continuous, endless loop would consume a significant amount of processor time. However, by blocking, the socket is only activated when data is received and as this is done automatically, there is no need to waste any computer time in a loop or additional coding efforts to check for data availability. The disadvantage of blocking is that it completely halts the execution of its thread whenever it waits. Therefore, any socket connection must be placed into their individual thread so as not to interfere with the rest of the Communication Module, as well as other MAMSDev modules and processes running on the Office server.

The Communication Module is also responsible for maintaining a continuous connection to the servers at the Aeris.Net central hub. These servers send regular “pings” to any connection that is made to it, to ensure that the connection is still valid. If no acknowledgement message is sent back, then the connection will be terminated. As well, other messages that are initiated by the Aeris.Net server usually require an acknowledgment or it will disconnect. The Communication Module has the necessary logic to recognize the message type and to return a suitable response or acknowledgement back to the servers to ensure the connection is not terminated. For messages sent from an asset, the raw data is extracted from the Aeris.Net message and passed onto the Data Module for further processing.

While there are a large number of unique message types that are used on the Aeris.Net MicroBurst service, all share a common format and binary encoding method. Each type has a header and limiter plus the actual message contents in between. The message contents include the metadata, such as the message length, message identification number

to distinguish its message type and the message body. As the messages share a similar structure, then it is natural to implement the different Aeris.Net message types as objects in MAMSDev by implementing Java classes to represent each message type.

A generic message class is implemented, acting as the overall parent or super-class on which all concrete Aeris.Net message classes will be based upon. This parent class defines certain basic and common behaviors for encoding and decoding the message contents to and from binary, which is relevant to all message classes. Further generic message classes subclass from the parent. These additional levels of generic message classes will be differentiated based on the message’s purposes, such as responses and data messages. They are more specific than the original parent and further add to or enhance the behaviors of the class. Ultimately, each Aeris.Net message type has their own concrete message class, supporting unique behaviors and functionality but inheriting from previous generic parent classes to reuse as much existing code as possible.

When a message is received from either of the Aeris.Net servers, the parent message class is first instantiated and given the message’s binary data to decode. The implementation of the decode function at the parent level is limited to decoding only the first few bytes to determine exactly what type of message it is. Once the message type is found, the parent class is cast into the identified message’s associated concrete class and the rest of binary data can be decoded into the raw message body using the concrete message class’ fully implemented decode functions.

encoded into the standard Aeris.Net format. The parent message class features an abstract implementation of this binary encoding function to encode the message contents into the binary format. This function contains the necessary code to encode the elements that are common to all messages, such as the header and delimiter. However, the code to encode the actual message body is left up to the concrete classes to implement.

A unique ability offered by MAMSDev for MAMS applications is the ability for users to remotely check on and control assets in real-time. This is possible through the integration of the Aeris.Net MicroBurst service with CSI Asset-Link sensors in MAMSDev. Users can issue a specific command through the Web Client to this module, which resides on an Office domain server. The Relay Server, using the Communication Module, sends the message onto the Aeris.Net’s AS server. Aeris.Net then proceeds to deliver the command by paging the onboard Asset-Link sensor which then performs the desired operation and reports back the success or failure of the operation as well as any results that may have occur. The Relay Server, like the Data Module, uses Servlets as its foundation because of the likelihood that multiple users would be accessing the Relay Server simultaneously. Once a command or page is received by the Relay Server, it then adds it to a queue at the Communication Module. The Communication Module will send out the pages to the Aeris.Net server, receive the response back from Aeris, and pass it back to the Relay Server, which will notify the user of the success or failure of the page. This module is also part of the Platform Layer and requires a small amount of configuration to work. An Asset-Link sensor can be preprogrammed to perform a series of operations, with each operation represented by a unique string of numbers. Operations that are of interest in

real-world applications include requests for current positions, unlocking doors, arming and unarming alarm systems, enabling or disabling engine ignition, speed limiters and continuous tracking. The configured operation and their numbered command strings are stored into the sensor database as the configuration can be unique for different sensors and/or asset combinations. For security reasons, the actual command strings and sensor identification numbers are never shown to users. Only users with sufficient security credentials have the ability to activate these commands.