Non-blocking firmware update for payment terminals
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Payment terminals often require firmware updates to enhance security, fix bugs, or implement new functionality, but they may be located in remote areas with infrequent network access, making traditional update methods inefficient and disruptive to operations.
Innovation Solution
A method for updating firmware in payment terminals that allows for non-blocking updates, enabling the terminal to process transactions while updating in the background, using a firmware manifest to determine which assets need updating and prioritizing critical updates, with the option to resume updates from a previous point if interrupted.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If firmware updates are performed using traditional methods that require network connectivity, then firmware can be updated to enhance security and fix bugs, but payment terminals located in remote areas with infrequent network access experience operational disruption and downtime
Solution Approach 1:
The system performs preliminary actions by downloading and storing firmware update packages in local storage memory before network connectivity is lost or becomes infrequent. The payment terminal prepares update candidates in advance, validating them locally, so that updates can be applied later without requiring real-time network access, thus maintaining both firmware reliability and transaction continuity.
2Reliability
If firmware updates are applied immediately upon receipt, then security vulnerabilities are addressed promptly, but payment terminal operations are halted causing downtime and loss of productivity
Solution Approach 1:
The system dynamically determines whether to apply firmware updates based on operational conditions. It implements a dual-mode approach: blocking updates (which halt operations for critical security fixes) and non-blocking updates (which are applied during idle periods or low-traffic times). This dynamic decision-making allows the system to balance security requirements with operational continuity, applying updates when it's safe to do so without causing unnecessary downtime.
Solution Approach 2:
The system performs preliminary validation and staging of firmware updates before actual application. Update candidates are downloaded, validated, and staged in advance, allowing the system to prepare for updates without immediately disrupting operations. This preliminary action enables smooth transitions and reduces the actual downtime when updates are applied.
3Productivity
If payment terminals in remote locations rely on infrequent network connections for firmware updates, then operational continuity is maintained, but firmware may become outdated reducing security and functionality
Solution Approach 1:
The system takes preliminary action by proactively checking for firmware updates whenever network connectivity is available, even briefly. It downloads update candidates during these opportunistic connection windows, validates them locally, and stores them for later application. This proactive approach ensures firmware stays current without requiring the terminal to be constantly online, maintaining both productivity and reliability.
Solution Approach 2:
The payment terminal performs self-service by autonomously managing its firmware update process. It independently checks for updates, downloads candidates, validates them, and schedules application without requiring continuous network access or manual intervention. This self-service capability allows remote terminals to maintain current firmware while preserving operational continuity during network outages.
Data Source
AI summary
A payment service system may include a server that manages firmware updates for payment devices such as payment readers. A payment reader may access a firmware manifest including a listing of current firmware assets stored at the payment reader, and send the firmware manifest to the server. The server may compare the firmware manifest to available firmware bundles, which are ordered combinations of firmware assets that have been released for usage by payment readers. Some of the bundles may be blocking bundles, while some are non-blocking. If a payment reader is to be updated with a blocking bundle, it cannot process payments during the update. If the update is not a blocking bundle, the payment reader may continue to process payments.