System engineering
A system engineer is responsible for overseeing the entire lifecycle of complex software and hardware product developments, ensuring all components work together efficiently and meet user needs. It begins by analyzing stakeholder requirements and then defining the essential functionality of the system early in the development cycle. This design then serves as the foundation for subsequent design and development.
In summary, a system engineer’s role in software and hardware product design and development surely includes delivering value to the end user.
OTA embedded firmware update
Over The Air (OTA) is the term used for updating firmware after the product is in use. The ‘Air’ part refers to the option to use Radio Frequency waves to send an updated firmware package to the device. Sometimes this firmware update is not done ‘over the air’ but by means of using an existing (or connecting a temporary) cable and transferring the updated firmware over the wires.
Being able to update the firmware is often used as a way to fix software (or even hardware) bugs and/or add planned functionality after the product is initially deployed.
Often creating OTA functionality in firmware is a bit like changing a car’s engine while it is already running. You need something to ‘talk to’ to start the update but account for the fact that the update might fail and still leave the product in a functional state. That usually requires enough space to have 2 versions of the firmware on board. The complexity and space requirement are some of the reasons why a product might not have this functionality.
Spraying crops
Farmers spray their land and crops multiple time per planting and harvest cycle. In the high-tech world of large scale precision farming, these spraying appliances can get pretty sophisticated.
Imagine a sprayer with the capability to adjust the amount to spray dynamically. This is derived from the speed of the appliance over ground, the volume of product the pumps can deliver, and the calculated amount of product that needs to be sprayed at that location of the field.
Consider a large sprayer with a span of 160ft and 320 individual prayer nozzles. Each nozzle is commanded by the central computer unit to deliver just the right amount, in the right place, all computed in real-time. A substantial cost saving on chemicals and a boon to the environment.
Not surprisingly this capability is complex and a software (or even hardware) update of these nozzles or central computer can be anticipated.
The firmware update
Turns out, in this case, each of the nozzles has a microprocessor that receives commands and adjusts the angle and amount of product to deliver. So, each of these nozzles has its own firmware.
And yes, this firmware can be updated but not in any streamlined, OTA, way.
Instead, each nozzle needs to be removed from the sprayer, connected to a computer which runs a firmware update program. That program first extracts the current firmware, then delivers the updated bits (overriding the existing version) and runs a test to verify all went well. Should it fail, it tries to send the original firmware back.
Most farmers will (have to) delegate this task to a dealer who will dispatch, and charge for, a technician. At the farm they will spend 30 or so hours to update the 320 nozzles. With OTA or similar, it would have taken less than an hour.
Imagine if the system engineers had specified that this procedure should be done without removing the nozzles and without having to connect each separately to a laptop? Or perhaps they did actually spec a streamlined firmware update and product management rejected it due to risk management and/or profit motives?