Production lines for the ParQSense sensor and base station
Two production lines for IoT parking hardware, built by a team that owned the electronics and the software together.
Software that builds physical products has an unusual property: the output is not a result on a screen, it is a device that leaves the building and cannot be patched afterwards.
Context
August 2018 to December 2019, at Q-Free ASA in Trondheim, in a supply chain team that owned both the hardware and the software for the production lines.
Two closely related projects, each producing one production line: one for single IoT parking sensor units, and one for the base station that multiple parking units communicate with.
The parking sensor is radar-based, and the units also use GPS. Both are physical measurements, which shapes what it means to verify one on a production line — a working unit is not one that runs without error, it is one whose measurements are correct.
Both lines were semi-automatic. Operators assembled units and moved them from one step of the production process to the next, which means the software had to account for a physical process running at its own pace alongside it.
The software for a production line covers more than it first appears to: business logic, calibration algorithms, encryption, communication over several protocols, real-time presentation of production data to the operators, visual and internal verification of produced units, and the design and printing of labels carrying manufacturing data.
My role
Developer. During the planning phase I contributed to Scrum planning and estimation of tasks. Through the rest of the project I worked on full-stack software development.
The team: project manager, hardware electrical engineer, three software engineers.
What was hard
The hardware integrations, and the radar and GPS in particular — both took a great deal of testing.
Verifying a physical measurement is a different problem from verifying a calculation. A radar reading or a GPS fix depends on the environment it is taken in, so the same unit on the same step does not produce an identical result twice. Test runs that behave that way need a lot of engineering to become dependable, and that robustness work was a substantial part of the software effort.
Outcome
One production line for the parking sensor units, and one for the base station.
Python · PyQt · Qt · C# · ASP.NET MVC · MySQL · Jenkins · Raspberry Pi · Ubuntu · Unit Testing