INTRODUCTION

ITR provides hardware, software and services that are focused entirely on reliability and condition monitoring. Company success is based solely upon the value of the tools and information they provide to our customers to facilitate their preventive maintenance planning and work.
World-class organizations use ITR’s predictive technologies to perform condition-based maintenance to prevent potential and actual failure modes before they adversely affect operations. ITR’s Predict to Prevent services help organizations worldwide improve uptime, safety, product quality, and energy efficiency.

BUSINESS OBJECTIVES

Help maintenance and reliability professionals better plan their maintenance activities;

• Periodically or continuously monitor critical assets using predictive technologies;

• Perform expert waveform analysis;

• Reporting timely, accurate and precise information;

• Identify problems before they occur;

• Increase MCU resources utilization efficiency: The objective is to optimize the use of MCU resources and reduce power consumption to ensure that the device is using minimum resources possible while data packets exchange;

• The objective is to improve sampling algorithm used for multi-stage filtering;

• Improve algorithm used for measuring the battery charge level;

• Adjust the process of storing data: The objective is to manage data properly providing reliable and optimal data storage;

• Maintainability: it should be easy to understand the application’s code and implemented logic, to add new features and fix bugs.

BUSINESS PROBLEM/OPPORTUNITY

• Inefficient use of MCU resources: If interaction of the XBee module with the MCU resources is not being used optimally, there may be a need to configure it and optimize the exchange of data packets, leading to lower power consumption and better utilization of the resources;

• Create a sampling algorithm with sampling frequency and multi-stage filtering during the process;

• Create an algorithm for measuring the battery charge level with the LiSOCl2 chemistry;

• Inadequate data storage: If the current storage solution is insufficient, there may be a need to upgrade the storage infrastructure to accommodate more data and ensure better data management.

APPROACH

In order to build a manageable delivery process we decided to use Kanban methodology. We use:

• JIRA for planning, tracking and managing issues that support an agile approach for project management; 

• Slack for online communication;

• Google meet for syncing meetings twice a week.

Our team started work on the project from analyzing the existing code for the coordinator and endpoint. After discussions, the main work stages were outlined using Kanban methodology.

The source code had hidden errors and was completely unreadable. Therefore, the first thing the team did was cosmetic refactoring using Google code style for C++ for better orientation in the code.

After checking the operability, the necessary changes in functionality were added in the second phase. 

Extensive documentation was created in Confluence. The main communication was conducted in Slack, as well as commenting on the documentation. All documentation shared a uniform style and versioning with detailed descriptions. This, in turn, made it possible for everyone to keep track of changes and view the project's progress.

In a bid to ensure the utmost security and accessibility, the project was divided into repositories that were stored on the customer's side on the dependable Microsoft Azure platform.

TECHNICAL DETAILS

The system comprises 3 types of devices: coordinator, endpoint, and repeater.

The coordinator is based on a single-board microcomputer, Raspberry Pi 4. An additional PCB features a connector for connecting the 4-20A communication module and DIGI XBee 3 PRO. Custom image based on Yocto Dunfell, some board support packages related only to Raspberry Pi 3/4. 

• Yocto image created for Raspberry Pi4, applications also as custom Yocto recipes;

• Initial main code consist over 10K lines, bad for the investigation and development;

• Main applications (four, communicates via mysql and with cloud) were separated to several files and libraries;

• Code was refactored with new comments, legacy and commented lines of code were deleted.

The firmware is built based on the Yocto system.

The endpoint is built on the TI microcontroller, a low-power MCU with a DSP processor for fast Fourier transform and signal filtering using FIR filters. The DIGI XBee 3 module is used for communication, while the battery provides power. The BQ microchip is used to measure its charge level. The firmware does not use any frameworks or RTOS for maximum energy efficiency and ease of modernization.

LESSONS LEARNED

• At the estimation stage, it is necessary to carefully research the source code and documentation so as not to exceed the deadlines due to the increased workload;

• Before starting the project it is necessary to review the current state of the product (firmware and hardware) to make sure we don’t need to do any refactoring and redesign of the PCB in order to unblock further development steps;

• The DSP processor greatly accelerates FIR filtering and allows it to be done in a separate thread;

• MSP430 is a powerful platform for future energy-efficient projects;

• Measuring the battery charge level in percentage with LiSOCl2 chemistry is currently very difficult, and the BQ35100 chip performs poorly in this regard;

• To ensure the best result when measuring the level of battery life, it is necessary to briefly connect a passive load as a resistor. The XBee module cannot act as a load because its power consumption is not constant;

• With XBee modules, a wireless network can be quickly configured using the Zigbee protocol (and others);

• In case of overloading the XBee module, it may continue to work, however, sometimes it can hang up completely. This behavior has been observed on almost all test subjects;

• Another key factor of success is the synchronization of all resources and technology aspects at the early stage of implementation so we use best practices of product and project management. Iomico didn't pay enough attention to the investigation stage before estimation: It was necessary to get full information about how devices should work and how they should be developed;

• Proper documentation is crucial: The project demonstrates the importance of proper documentation of the system's architecture, design, and implementation. Documentation helps to ensure that everyone in the team has a clear understanding of the system's functionality, and it can be used as a reference when making future changes or improvements;

• We need to increase complexity coefficient due to lack of documentation bringing this to the customer attention;

• Get customer approve before making big changes (like Igor did with Yocto) because even with experience he had troubles which required time; 

• It's not a good idea to have a part-time developer in terms of efficiency, because it is so hard to refactor/understand/investigate the project so it is necessary to be involved constantly and not to switch to other projects. It makes a gap of several (4 months for current moment) months between each developer finishing their stage/task for Endpoint and for Coordinator. That’s why the code cannot be tested in interaction between both devices after changes have been made.

CONCLUSION

It is very important to make an investigation of the current hardware and firmware before scoping and estimation. Comparing the AS-IS state of the product with the TO-BE state (based on the gathered requirements) gives us a clear understanding of the scope of work and timelines be closer to exact deadlines.

Ensure maintainability: The requirement for easy maintainability is important for any software project, but particularly for this one, given that it may require frequent updates and feature additions. It is important to write clean, modular code and use appropriate software design patterns to make the application easy to understand and modify.

The best way to reduce customer concerns for such projects (bad code, pure documentation, there are no touchable results for a long time) is to prepare a presentation like a retrospective showing what has been done and explaining why it is necessary and what profit these changes have for the future.

iomico should offer to allocate resources more efficiently according to the project workload (2 full-time developers).

Overall, the project is a significant achievement that demonstrates the team's expertise in designing and implementing a sophisticated system. The system's functionality and features make it an excellent solution for Industrial technology research, and the lessons learned from the project will be invaluable to future endeavors.