A core ideology of a product is usually planned in many stages before the actual production. It is customary to produce several prototype versions including the successful features from the previous stages and new changes which are often being tested for usability at the current stage. After completing the production stages, the usual practice comprises branding and installation. At this point, the product is proven to fulfill the underlying core concepts that are needed in the project. Even though this is necessary for any product that comes for the market, there is a question that arises.
“Does this method guarantee uncomplicated user experience throughout lifetime? ”
The ultimate goal of a product should be the satisfaction of the user. The end-user must not be exposed to the design complexity of the product to interact with it. At the same time, the product should be alert of potential erroneous situations it might endure in the future. These improvements might take a significant amount of time in the development phase but definitively enhances the product’s quality. Given that there are many ways one can approach this, I have added included of the main ideologies used by myself during the internship in the company
1. Continuous Error Detection and Correction
Even though there will be thorough planning sessions conducted during a development phase of a product, there can be some unexpected errors prompted during functioning. Finding and correcting these errors regardless of their severity is a healthy process. They include several steps as stated below.
- Keeping an entry of potential errors that can occur during the development/action.
- Keeping tabs on any changes that have been done in the process deviating from the actual design considerations. (Change of parts, Algorithms, etc.)
- Conduct test runs in the actual working environments with all the conditions present as they are going to be. Construct cross-checking mechanisms (preferably real time) that would give out the error at runtime. I overlooked the real time readings in over the MQTT dashboard to spot errors.
The last step ensures the operability of the product in its own environment. What if there are errors spotted at any of the above measures?
- Start making an error analysis document. Copy every entries you have made during the development made as mentioned above.
- Start short listing hypothesises in a grouped manner (errors related to the firmware, errors related to the hardware, errors related to the software etc.)
- One by one, start testing hypothesis and add the results to the document until the error is revised.
- When testing, make appropriate test benches and use the actual results for comparison.
2. Remote configuration of the product
Most of the company’s products publishes or acquires data from MQTT/HTTP medium. The data published by the sensor/product is constructed in such a way that the associated software could translate and display it to the user in a user friendly manner.
What if this behaviour needs to be altered? What if the developer/user wishes to configure the device in a different way so it is more beneficial for the purpose?
Reprogramming the device in the traditional way could be tedious given some of the devices could be installed in places that are difficult to access (E.g. Under the soil, onto a critical part of a machine). We had to come up with a feasible teachnique which could tackle this problem.
As we are already using a GSM based module to send/receive data, we decided to utilize a method that could involve the same hardware. To achieve the prefered method, the below ordering has taken into consideration.
- Enable MQTT subscribe routine on every device during development.
- Publishing a string containing the below parameters that needs to be altered in the configuration to the topic “Configuration”.
– Device ID - Used for identification of the device
– Publish message ordering
– Topic to publish.
– Publish interval. - Switching the device to configuration mode by triggering a short button press interrupt.
- The device commences the subscribe routine and gets the above message.
- Configuration is done in two steps.
– Comparing the Device ID and proceed with the changes only if the ID is same as its own.
– Alters the above parameters in the original firmware and exit the configuration mode to perform normally.
The above method enables regular adaptability of the product without requiring manual operation.
3. Calibration of the product
During the installation of the product, there are situations that the output or some sensor readings to be needs to be fine tuned to match with the environment of the product. This process is called the “Calibration”. While all of these readings may not be visible in the published data, we need to have a method to listen to them at calibration. This process is lot similar to the one above. The realization steps as follows,
- Enable MQTT subscribe routine on every device during development.
- Publishing a string containing the below parameters that needs to be published to the topic “Calibration”.
– Device ID
– Port to be listened.
– Publish interval during calibration. - Switching the device to configuration mode by triggering a long button press interrupt.
- The device commences the subscribe routine and gets the above message.
- Calibration is also done in the steps mentioned above.
4. Automated Testing
Has it ever occured to you that after developing a significant amount of the project with constrained timelines, a few peripherals in the manufactured PCB malfunction? This is common problem in the embedded system development. While it is almost impossible to avert this problem completely, we brainstormed ideas to make early detection possible and does not require any expensive addition to the budget. We are trying to implement this in following simple steps.
- Identifying common peripherals and technologies used in the projects (E.g. Bluetooth/BLE, GSM, 3G, LoRa, USB etc.)
- Construct a set of testbenches to test the functionality of the above peripherals when the PCB is used for the first time
- Using a tailored subset of the above for each PCB of the received batch.
- Detection and recording of the malfunctions if there are any
Combined with the routine Power and basic functionality tests, this method can save a lot of time and effort wasted in the normal operation.
5. Error Logging
While the above error detection methods mentioned above are very effective during development, we need more advanced techniques to pinpoint any errors that could happen after the installation. These kind of errors might happen due to several reasons including connectivity problems, change of the environment, physical damages over time etc. For example, how do you find errors using a remote platform if the connection is corrupted?
In this case, the errors must be recorded in such a way that the developer could access them even if the product is resetted during the operation. Flash memory is a great resource that can be used to focus on the problem. It is used in this scenario for its ability to,
- Flash memory is not erased during reset.
- The memory is divided into sectors, which enables sector erasing without erasing the whole memory for continued usage.
- • Flash is readily available in the product. The need for external hardware is avoided.
- Even though the read/write rate of the flash memory is comparatively low, it is sufficient for this scenario.
The below steps are taken in order to address this problem
- Define and label any problems that the product might endure during operation in a dictionary.
- Direct the firmware to write the index given for the error to the flash at every erroneous event that occurs during operation.
- When in such scenario, the user/developer could plugin the USB port to a system to read the flash to find the exact problem that causes the device to malfunction.
6. Conclusion
Sticking to the main functionality during the planning and developing stages could be detrimental for its lifetime operation. Inclusion of the Error documentation, Remote configuration, Calibration, Automated tests and Error logging could improve the performance of the product significantly. All of the above mentioned methods are highly effective in terms of cost and time consumption during operation.