Firmware Integration & Test Systems Engineer Prowinch

LLC - 4.5

Miami, FL Job Details Full-time 2 hours ago Benefits Paid time off Qualifications Electronics test execution Engineering development testing Software troubleshooting Embedded systems Firmware English Firmware development Linux Hardware diagnostics

Python Debugging Full Job Description Benefits:

Competitive salary Paid time off Training & development Overall Summary The Firmware Integration & Test Systems Engineer is a systems-focused engineer responsible for making sure the different software and firmware components of MilaY work correctly together. This is not primarily a firmware-development position and it is not a traditional QA role. The engineer builds the automated test infrastructure, simulators, diagnostic tools, and integration environments needed to test system behavior across component boundaries. MilaY is composed of multiple independently developed systems, including the machine and its firmware, the mobile application, the relational backend, and the telemetry backend. The machine firmware is developed externally and communicates with ProWinch systems through defined interfaces. As the project grows to support additional firmware versions, hardware configurations, and ProWinch equipment platforms, manually verifying every combination becomes increasingly difficult and creates a substantial regression risk. The primary responsibility of this engineer is to build a repeatable Software-in-the-Loop and Hardware-in-the-Loop testing capability . The goal is to allow firmware and other MilaY components to be exercised automatically under realistic operating conditions without requiring every test to be performed manually on a physical machine. The engineer would create firmware simulators, test harnesses, protocol tests, fault-injection capabilities, compatibility tests, and automated integration scenarios that can eventually run as part of the project's CI/CD pipelines. A strong candidate will normally have experience spanning embedded software and software test infrastructure. Expected strengths include C/C++, Python automation, firmware debugging, automated integration testing, Software-in-the-Loop testing, binary protocol testing, Linux, fault injection, and CI/CD. Hardware-in-the-Loop testing, simulator development, CAN/CANopen, protocol analysis, and device communication testing are particularly valuable. MilaY-specific technologies such as

BLE, MQTT, USB

CDC, X.509/TLS, and industrial automation are additional advantages. This engineer also serves an important cross-team integration function . When the mobile application, firmware, or backend behaves differently from the documented interface, the integration test environment should help determine where the incompatibility exists. Instead of relying on one team's implementation as the definition of correct behavior, tests can be built against the agreed protocol and system contracts. The role becomes increasingly important as MilaY supports more hardware platforms and firmware versions. Without this capability, compatibility testing tends to depend on developers manually connecting applications to physical boards and reproducing specific conditions. That approach becomes slower and less reliable as the number of supported combinations increases. A dedicated integration test system provides repeatable regression testing, earlier detection of interface problems, controlled fault testing, and evidence that specific combinations of firmware and MilaY software have been validated. In practical terms, this candidate represents the engineer who builds the infrastructure that allows ProWinch to answer questions such as: Does the new firmware still work with the current mobile application? Does the application behave correctly with older supported firmware? Does a firmware command conform to the documented binary protocol? What happens when packets are lost, corrupted, delayed, or rejected? Does the system recover correctly after a connection or firmware failure? Does telemetry generated by the firmware match the expected format and behavior? Can the same test scenario run against a simulator today and real hardware later? Which combinations of application, firmware, protocol, and hardware configuration have actually been tested? The long-term objective is a testing environment where important system behaviors can be exercised automatically against simulated firmware during normal development and then validated against real boards through Hardware-in-the-Loop testing. This reduces dependence on manual integration testing and gives the project a scalable way to manage firmware compatibility as MilaY expands.

Requirements:

English ( Fluent), written and spoken. Skills Tier 1: Core Embedded C/C++ Python automation Automated integration testing Firmware debugging Software-in-the-Loop testing Test harness development Binary protocol testing Linux Fault injection CI/CD Tier 2: Highly desirable Hardware-in-the-Loop Simulator development CAN/CANopen Protocol analysis Hardware/software debugging Docker/reproducible test environments Firmware compatibility testing Device communication testing Tier 3: MilaY-specific advantages

BLE MQTT USB CDC

Azure DevOps

X.509/TLS

Industrial automation Hoists/cranes/motor controls Tools and Technologies Embedded development GCC/Clang, CMake, GDB J-Link, OpenOCD, or comparable

JTAG/SWD

tools Testing and simulation pytest GoogleTest, Catch2, Unity/CMock, or similar Renode, QEMU, or comparable firmware simulation/emulation environments Industrial and device communications CANoe / CANalyzer SocketCAN / virtual CAN Wireshark nRF Connect / BLE diagnostic tools Mosquitto / MQTT tooling USB/serial diagnostic tools Hardware integration Logic analyzers Oscilloscopes CAN interfaces Programmable power and test equipment Automation and infrastructure Docker / Docker Compose Azure DevOps Pipelines, Jenkins, GitHub Actions, or similar Git Linux development and diagnostic utilities