Smartrak’s Marketing Communications Manager, Matthew Perkins, and Director of R&D, David Chell, discuss the guiding methodologies behind custom solution development for enterprise-level fleets.
Matthew Perkins: As a company dedicated to delivering positive change for our customers, we’ve been tasked with creating numerous custom solutions for a wide variety of operational environments. Commissioning this kind of bespoke development can be a scary process for customers and I wondered how Smartrak’s R&D approach addresses this issue?
David Chell: The important factor to consider when discussing customisation is that your customers want the shortest route possible to a viable solution. They are not into customised developments for the sake of innovation. They are looking for business tools and if they could use an off-the-shelf solution to do the job they would.
MP: So how does this realisation guide Smartrak’s development process?
DC: At the heart of our solution offering we have Software as a Service (SaaS) products. This means that the innovative intelligence is vested in a software product that’s always able to evolve in response to changing customer demands. Where hardware is required to enable a solution we choose the best available for a particular application and then tightly integrate that into our software product via purpose-built middleware.
MP: What does that approach look like in practice?
DC: Smartrak has enterprise-level customers across the government and business sectors, and in each case they have distinct operational goals that they want the technology to achieve. It’s the job of our solution engineers to analyse that requirement so that we can turn an operational need into a technology solution.
For a very large company in the dairy industry this resulted in Smartrak delivering a smart solution for their large fleet of around 500 tankers. By integrating the existing peripheral hardware components on a tanker with our solution we increased accuracy and reliability around the collection of perishable liquids, alongside providing a modular pathway for new technology.
DC: Yes, the solution is made up of various components, or modules, such as the hardware that already existed in the tankers. In this case, Smartrak built an entirely bespoke solution from the ground up. It was designed to replace and provide feature parity with the previous system. But as with our solutions that use Smartrak’s platform as a base, there is still the capability to support continual enhancement. Whether that’s to meet compliance, health and safety, productivity or food safety requirements. The heart of the system and the accumulated wisdom that’s been acquired isn’t affected. This makes adoption of new technology easier and cheaper.
Another example involved custom-designed and built hardware, because there wasn’t an off-the-shelf solution, which was integrated with standard Smartrak hardware. This was for a public transport provider in Australia. Our solution provided data and in-vehicle passenger HID. Along with APIs to support scheduling and route reporting.
MP: What are some examples from the government sector?
DC: We have Police and Fire and Emergency organisations who depend on customised Smartrak solutions, which are seamlessly integrated into their existing systems. This deep integration provides both organisations with an extensive tool kit of customised support features.
For Police, this entailed integrating the Smartrak's personal safety solutions and reporting with Police systems.
The solution for the Fire and Emergency organisation utilised standard AVL-GPS units and a customised software solution. We were able to provide carrier redundancy, hardware redundancy, and Dead Reckoning with a supporting speed sensor connected to CAN Bus. The Dead Reckoning feature enables the device to work out change of direction, current speed and direction of travel, and then simulate the expected GPS positions, when no GPS satellite signal is available.
MP: Developing the right solution obviously involves a lot of moving parts.
DC: Yes it does, it’s a complex process, but you still have to focus on usability. Providing system users with Single-Sign-On so there isn’t a rigmarole every time they log on is important if innovation is going to be an everyday advantage. And presenting the data so it provides useable information that managers can easily interpret is important too.
MP: Can you touch on information security and reliability.
DC: Secure data transfer from devices in the field to the system platform is achieved via Smartrak’s private APN. This is a secure, dedicated traffic tunnel over the cellular network containing encapsulated data. The information that’s held within the reporting devices is also encrypted and secured. There is no access to this by system users.
The customer also has full capability to enable or restrict access to various levels of the system based on authorisation.
To ensure the information being collected is reliable, we process the raw data, filtering it through Smartrak’s logic algorithms. This utilises a range of methodologies, including contextual expectation to enhance the accuracy and relevance of the data. Smartrak also uses a powerful, open-source object-relational database system called PostgreSQL. With over 30 years of active development, PostgreSQL has earned a strong reputation for reliability, data integrity, feature robustness, and performance.
MP: So Smartrak is the complete solution provider?
DC: Yes, we assume the responsibility for our customised solutions, even when we’re inducting third-party components – it’s our solution architecture and we have to ensure that our customers can have complete confidence in it.