News & Blog
Considerations when selecting hardware for your application
So, you’ve already got the application in place, either an existing solution, your newly created application or white label licenced product. Now you’re ready to select, upgrade or replace your point of touch within the vehicle or host equipment, the telematics device itself.
With such an array of devices and options out there, how do you make the selection and what are the pitfalls you need to avoid? We’re not looking to answer these points here, that’s for another discussion, but we’re looking to create a considered check list and start a conversation, leading to the selection process.
Functional Requirements
Firstly, we need to look at the functional requirements, the physical and outline ‘must haves’ to ensure your hardware is suitable and fit for the intended use case:
- Appropriate network technologies (e.g. 2G or 3G or 4G, Satellite or local WiFi or Bluetooth) and specific regional frequency for cellular – Understanding what technologies are needed based on the physical and geographic use location of the host.
- Supported location technologies GNSS, GPS or cellular based tracking. Again, the geographic use location is needed to understand what can and can’t be used and what’s important.
- Appropriate interfacing for accessories supported (i/o, serial port etc.). The accessories needed will vary based on what the application can support, the demands of your client-base and the physical environment of the install (i.e. what type of vehicle or equipment)
- SMS support. Depending on the level of SMS required, incoming for changes to configuration etc., requesting a report or response, confirmation of configuration or initiating a device event (e.g. trigger immobilisation). Or outgoing SMS for reporting or a response to a triggered event.
- Physical size. Does the device meet the installation requirements in terms of physical space available or covert nature of an install?
- Environmental considerations based on install location e.g. temperature, moisture, vibration or specific IP rating. No point having a device that can’t handle the environment it will be installed into e.g. in an engine bay that can have excessive heat, dust, dirt and vibration.
- Appropriate install and mounting methodology supported. Cable types needed, connectorised or captive wiring harness, physical install location and mounting within the host (such as a mounting plate, screwed, cable ties or sticky pad) protection from disconnection due to environment, vibration or user interference.
- External or Internal Antenna. Are you going to be able to get signal at the point of install, for the technology selected, is there availability of GPS? Although embedded antenna technologies are very efficient, sometimes you need to firstly select a device that supports external antenna (for both or either cellular or GPS) and the appropriate antenna type to ensure good quality and robust connection e.g. combined or separate, dash mounted, screen mounted or internal or external body mount.
Technical Requirements
Over and above the functional specification we now need to look deeper into what is technically needed to achieve the functional requirement and ensure effective communication to your application:
- Appropriate message transport protocol, UDP or TCP, SMS. Before we get into the details of the device we need to ensure that the messages are going to be suitable for your application server. Most use UDP for the smaller data overhead but more increasingly we see TCP being required as applications are migrated or combined with wider IT solutions. SMS to/from the server might also be a consideration here for use in recovery situations or where there’s no data channel available (low cellular signal areas).
- Suitable data format, message format. Can your application accept the message format from the device, do you have the appropriate listeners or parsers?
- Acknowledgement. Do you need the server to acknowledge package receipt, what happens if it doesn’t? We’ve seen many applications fail to plan for this resulting in massive data use as the device may continue to resend data.
- Firmware updates. How do you plan to update the firmware on the device, most units will be in situ for a long period of time, doesn’t it make sense to have the ability to update the manufacturers firmware as required?
- Configuration updates. Is there a plan to cover the need to roll out any configuration changes to cover bug fixes, changes in terms of use, reporting rates, changes to endpoint server or connectivity?
- Recovery. What happens if the device stops reporting? Is there a plan in place to initiate device reset?
Technical Requirements – Hardware
In addition to the above we also need to look at the physical hardware and ensure that it has the ability to provide the interfacing and information needed:
- Power Consumption. Is the host able to provide the right amount of power? Does the device draw too much power in certain situations? e.g. Will it drain the vehicle battery if left unused/unattended for a period of time?
- i/o. Does the device have the right number of Digital and Analog Inputs/Outputs required?
- Accessories. Does the device support the accessories required? e.g. 1-wire, Driver ID, drive for LED display or driver feedback, push buttons, buzzers or Immobilisation.
- Accelerometer. If looking for driver behaviour or motion detect, does the device have the appropriate accelerometer on-board?
- Serial interface(s). Is there the appropriate serial interface for any 3rd party devices or systems we might want to interact with?
- Internal Battery. Is there an internal battery for disconnection notices, last gasp reporting or power outage situations?
Commercial requirements
Once we’ve covered all of the above then we need to reduce our short-list further by ensuring that we have a device that meets the commercial requirements, remembering that price isn’t everything, we need to consider the unseen costs (i.e. the PRICE of the device is only part of the COST!) and does your business model support or budget it?
- Device cost. Not just the base device cost, we need to consider the true cost allowing for any import, shipping or currency exchange involved.
- Cable costs. Is the cable cost included, if not what are the options and costs involved (factoring in the same considerations as for the device itself).
- Accessory hardware. Can be a large part of the solution costs, we need to look at the accessories needed, how they’re interfaced and the overall package cost
- Installation cost. As it suggests, the overall cost of installing the solution into the host, some use their own install teams but most use 3rd party companies but both options should be costed.
- SIM costs. Remembering that these are M2M (machine to machine) devices, the appropriate data package and SMS content is crucial to covering long term use and costs. There are lots of excellent companies out there with great understanding and packages for M2M & IoT applications.
- Integration costs. Largely ignored but can be significant, what is the cost of integrating to your application, in terms of man hours writing the appropriate server-side support for the device? Time spent learning and writing new device configurations and maintaining the configuration. What could be the likely cost of getting something wrong? All need to be considered.
- Future costs. Once installed and operational, what is the plan for maintainance and/or future replacement for adding features or failure? What happens at the end of the end user term and is there a plan to get continued use and revenue beyond this point?
As you’ll see from the above and by no means are these lists complete or definitive, there’s a lot to consider and as stated this is the start of a conversation.