3 options to reduce your data consumption by up to 94%
A unique strength of the Proemion solution is the ability to configure the devices to smartly process telematics data on-edge, reducing the data consumption by up to 94%. Proemion closely cooperates with OEMs and suggests solutions for achieving the best balance between data integrity and data consumption.
We have compiled three options that can help to create this balance. With the Proemion Configurator, the opportunities presented here can also be made by you as an OEM without the help of a Field Applications Engineer (FAE).
The Proemion Configurator is Proemion's alternative to high-level software development frameworks. It allows people without software engineering skills to develop and maintain telematics applications. The Proemion Configurator offers a high degree of flexibility to the OEM by implementing their processes and non-volatile variables. The software makes it possible to create complex applications such as a digital filter or UDS parser with relative ease.
Proemion's FAE team also uses the Proemion Configurator to configure our customers' TCU if needed. Years of experience have led to best practices, including these three best practices for minimizing data consumption.
OEMs' typical concern is the amount of data transmitted by the IoT Gateway over the cellular network. If all CAN bus data were logged, it would range between 500 MB to 2 GB or more per machine per month. Sending such high amounts of data is undesirable because of the cost of cellular data transmission and, more importantly, the cost of storage, processing speed, and data retrieval latency. After all, it is essential to remember that data alone is not valuable. The insights we can gain from the information provide the most significant benefits of a telematics' deployment.
With these FAE best practices, you can minimize data consumption by merely logging the data selectively based on your business's most insightful parameters.
Delta threshold-based logging
One of the options Proemion uses to reduce data usage without losing data integrity is delta threshold-based logging. Delta threshold-based logging minimizes data consumption by only logging data when a change exceeds a defined parameter (threshold).
For example, OEMs can use the Configurator to define that "engine speed" is logged every time it changes by ±100 rpm or another measure. In this case, any sudden large fluctuations in "engine speed" are immediately recorded. Still, if the "engine speed" is relatively constant, it is not logged, and no data is used.
Configuration for delta threshold-based logging.
Configuration for dynamically adjustable delta thresholds
Dynamically adjustable delta thresholds
Going one step further than delta threshold logging, dynamically adjustable delta thresholds allow you to set conditions that further fine-tune data usage. This option will enable you to collect more data when required and less when it is not.
For example, "DOC outlet temperature" can be logged every ±50 °C when this signal indicates less than 40 °C. But decrease the delta threshold to ±20 °C when the signal is over 40 °C, allowing a higher granularity in the logged data when necessary and can benefit data analysis.
Condition-based logging
It's important to know that some signals may not need to be logged at all unless they change value. Bitfield signals such as lamp status, DTCs, ECU software version are good examples. You can easily set up condition-based logging by merely checking the "valid on change" option in the Configurator. This way, you specify that the data is only logged when the received signal changes.
Configuration for condition-based logging
Summary
Following these best practices from our Field Application Engineers can help your organization reduce the amount of data consumption necessary for logging CAN data to monthly levels as low as 10-20 MB. By reducing the amount of data transmitted and stored, your organization can also realize faster processing speeds and reduced data retrieval latency.
A unique strength of the Proemion solution is the ability to configure the devices to smartly process telematics data on-edge, reducing the data consumption by up to 94%.
About the Proemion Configurator
Proemion has over 30 years of experience developing CAN bus-related embedded systems and more than 20 years of experience in IoT Gateways. What sets Proemion's telematics solution apart from other Off-highway OEM solutions is that everything is developed and produced in-house. Hardware development and production, embedded software (also known as firmware) development, and high-level application development come from one provider. This allows Proemion to develop a very stable hardware and software solution specializing in CAN bus data and utilizing the J1939, KWP2000, UDS CAN bus, and other protocols.
Over the years, Proemion has developed a further abstraction layer, the Proemion Configurator, focused on CAN bus communication and telematics' combined needs. It offers a different approach to developing embedded software applications by constraining the IoT application developer to only use tested and tried methods, which have been fine-tuned for the CANlink mobile hardware and provide a safeguard from embedded software difficulties development.
Proemion configurator supported protocols
The Proemion configurator allows the definition of applications at different layers in the ISO/OSI model.
The foundation for any CAN bus application is the CAN layer 2 (ISO 11898-1). An application can be defined by allowing the reception of a single CAN ID (or multiples ones with the help of a bitmask). Optionally applying down-sampling and selecting which data bytes are to be logged and sent to the Proemion Data Platform.
When developing J1939 applications, the Proemion Configurator offers a high-level toolkit allowing the definition of received messages by PGNs. This toolkit automatically handles multi-frame messages such as TP.CM & TP.DT used for DTC BAMs.
The Proemion Configurator also offers convenient handling of ISO-TP multi-frame messages at the transport layer (ISO 15765-2). It allows the development of OBD, KWP2000, or UDS-based applications, with the latter being increasingly in demand. While the Proemion Configurator at version 3.0.0.0 (August 2020) does not offer an application layer toolkit for OBD, KWP2000, or UDS (like it does for J1939), it is so powerful that the Proemion FAE team easily developed a parser for some demanding UDS-based applications. If market demand for UDS logging continues, the Proemion Configurator will most certainly offer more high-level toolkits for easily developing demanding UDS-based applications.
Questions?
Speak to an expert.
