Evangeline Minet

E1 · E2Contec Americas2025 – present

A digital thread for embedded systems

Python digital twin models that tie system architecture, CAD geometry and operational telemetry into one traceable engineering repository.

Problem

System architecture, CAD, test data and configuration records lived in separate systems, and keeping them consistent took manual reconciliation.

What I built

Digital twin models in Python that connect architecture, geometry and telemetry. Automated pipelines and REST API connectors between engineering repositories, test data and configuration management. Data contracts and interface specifications agreed with mechanical, electrical and software teams. The AI side is full stack, from research and development through to the software that ships, and much of the role has been R&D.

Verification

Requirements, their verification and their traceability managed in the Altium 365 Requirements & Systems Portal, alongside Altium Designer. Traceability matrices that run from system requirements through sub-system interfaces and design decisions to test cases and acceptance evidence. V&V planning coordinated across system boundaries. Code written with AI assistance is verified independently.

Outcome

Automated pipelines replaced manual data reconciliation, and design revisions stay under configuration control.

Python · REST APIs · Full-stack AI · R&D · Digital twin · Traceability · Configuration management Proprietary work, described in general terms.

E11Contec Americas2025 – present

Release control for a regulated fleet in seven countries

The master control platform for the regional hubs that provision the laptops paired with intraoral scanners made by one of the world’s largest dental-technology companies, best known for clear aligners. The hubs set up 200 to 1,000 laptops a month. The platform runs software releases, sync, monitoring, security scanning and regulatory change control, with a portal the customer uses too, and all of it runs on a Raspberry Pi CM5.

Problem

Under ISO 13485, a country’s hub may only serve a software release once that country’s regulator has approved it. The hubs sit on networks that are reachable only part of the time. Approvals, releases and what each hub actually runs had to agree, with an audit trail anyone could inspect.

What I built

• A change-control portal (Python, PostgreSQL) showing, per country, the release each hub runs and the one it’s scheduled for, next to its regulatory approval. A hub that serves, or is set to receive, an unapproved release is flagged red. The approval history is append-only, enforced by database triggers.
• Deployments that must pass every gate before they run: the release is approved for that country, its frozen snapshot passes checksum and manifest checks, a dry run of the same deploy passed in the last 30 minutes, and the operator types the region code. One deploy runs at a time, and every one is logged.
• Frozen, checksummed release snapshots, so one country can stay on an older approved release while others move ahead. Contec’s infrastructure layer is versioned separately from the customer’s release layer; I verified that combining them reproduces production byte for byte.
• The master server itself and its command-line suite for version management and promotion from development to production, which I built on my own before I used any AI assistance, plus Ansible playbooks to provision hubs and push configuration.

Verification

• A software bill of materials for each release, reconciled against the customer’s engineering change orders and exported as CycloneDX 1.5. Checking one 5.5 GB release package caught real defects in it before production: a 19 KB web page shipped in place of a 3.27 GB CUDA installer, and a mislabeled component.
• Daily Syft and Grype scans of the host and every container, measured against a baseline so only new findings are reported, for EU Cyber Resilience Act vulnerability handling. The automated scan showed that an earlier hand-built SBOM had undercounted.

Operations

• Every sync run records its result in PostgreSQL, and a Grafana dashboard shows each region’s health, late jobs and run times. It surfaced regions that had gone quiet and a nightly push job that had been failing silently.
• Traced a fleet-wide outage from a drop in sync run time, 33 s to 1.4 s, to a boot race between NetworkManager and Tailscale that overwrote DNS, and wrote a repeatable fix.
• Moved sync from one global sweep to per-region timers in each hub’s local business hours, using IANA time zones so schedules hold through daylight-saving changes. Decommissioned one regional hub.

Customer access

Cloudflare Access sign-in, validated on the server and failing closed, limited to an email-domain allow-list with separate admin and viewer roles. Customer viewers never see internal hostnames, paths or errors, and admins can preview exactly what they see. Provisioning and audit records are permanent: the database refuses updates and deletes, and backups run nightly.

Status

In daily use for release tracking, monitoring and scanning. Built but not yet switched on: one-click deploys from the portal, and hubs re-syncing themselves when they boot.

Raspberry Pi CM5 · Python · PostgreSQL · Ansible · Docker · Grafana · InfluxDB · systemd · Cloudflare Zero Trust · Tailscale · Syft & Grype · CycloneDX Proprietary work; the customer isn’t named.

E12Contec Americas2026

Product security and EU Cyber Resilience Act reporting

I run Contec Americas’ product security incident response team (PSIRT) and lead its readiness for Article 14 of the EU Cyber Resilience Act, which since September 11, 2026 requires manufacturers to report actively exploited vulnerabilities and severe incidents within 24 hours.

Problem

Contec Americas is a hardware integrator: it buys PC hardware, installs the operating system and customer software, and sells configured units, some of them medical devices. Most fixes come from suppliers, as BIOS, OS and third-party patches, so incident response is mostly supplier coordination, and the reporting clock still applies.

What I built

• The PSIRT operating policy, adapted from the parent company’s IEC 62443-4-1 policy: four lean roles, CVSS and CWE severity ranking, coordination with the parent company’s PSIRT on shared components, and a CRA appendix with the 24-hour, 72-hour and final-report deadlines. Released in 2026.
• Registration on ENISA’s Single Reporting Platform through the company’s EU branch, verified by the national CSIRT.
• An incident-record design for the company’s ERP, taken in stages from design to field dictionary, JSON schema and HTML mockup. The legal clock starts at the moment of awareness, so every timestamp has a UTC copy, and submissions are kept as immutable records with SHA-256 hashes.
• A field toolkit on a six-partition USB drive that collects firmware and software inventories from Contec products on Linux and Windows and converts them to CycloneDX 1.6 SBOMs. On medical devices it only reads, and it avoids Windows queries that would make installers reconfigure themselves.

Status

Policy released and the reporting platform registered. Next: a timed dry run of a 24-hour report, an on-call roster, and mapping products to the EU markets they ship to.

EU CRA · IEC 62443-4-1 · ENISA SRP · CVSS · CWE · CycloneDX 1.6 · Bash · PowerShell · Python Proprietary work, described in general terms.

Contec Americas2025 – 2026

Argus: edge AI and an OpenUSD twin of a warehouse

Packages that turn up damaged at a receiving dock, with nobody able to say whether they came off the truck that way. Argus puts vision on the dock with a fanless Contec PC and no NVIDIA GPU, so video never leaves the building, and writes what the cameras see into an OpenUSD stage of the whole warehouse. The browser and NVIDIA Omniverse render that same stage, live, once a second.

What I built

• Edge inference: YOLOv8n with the backbone compiled for a MemryX accelerator and the detection head on the CPU (ONNX Runtime), about 37 ms a frame, on two 4K cameras covering the bay doors and the room interior. An IoU tracker gives detections stable IDs, and a per-camera homography, calibrated in a browser point-picker, puts each one on the floor in meters.
• A layered OpenUSD stage: a live layer rewritten every second, a cameras layer with calibrated poses, a layout layer generated from the site CAD (building shell, 15 openings, 71 fixtures, floor markings), and an assets layer. Every prim carries argus:* attributes (class, track ID, camera, zone, door state, pose source) that the browser and Omniverse tools both read.
• Views on that one stage: a three.js 3D twin and a 2D plan, a shared layout editor, an occupancy heatmap over any window from an hour to a month, and replay of up to 24 hours at up to 300×, drawn from 3.48 million logged floor positions over 102 days. An Omniverse Kit extension hot-swaps the live layer each second.
• The first phase: an I/O daemon that is the only owner of the Modbus link to a Contec remote I/O unit driving a 12 V stack light, with MQTT/InfluxDB telemetry and an SVG floor plan of the docks.

What broke, and what changed

• A heuristic damage scorer, run before any trained model existed, fired 678,044 incidents in 18 days, nearly all false. I muted it, archived the flood, and moved to a labeled dataset (1,605 images queued) for a trained detector. A detector that can’t say no is worse than none.
• The twin segfaulted within seconds under 16 concurrent clients: one thread force-reloaded USD layers while another composed the stage. Now request threads never touch USD; one writer thread owns the stage and HTTP serves a cached scene. A stress run afterwards: 5,825 of 5,825 requests OK.
• Two services opened the same accelerator and starved each other. Inference moved into one service, and the other became a health watchdog: one owner per device, enforced by the service layout. The same rule runs the Modbus link, where the I/O unit’s own watchdog returns every output to a safe state if Argus crashes.
• At one write a second, layer files often change within one timestamp tick, so a plain reload skipped them and the twin froze. Layers now force-reload, and writes go through atomic rename so no reader sees half a stage.
• Bay doors were first guessed at 3.66 m; the CAD said 2.44 m. Every dimension still unmeasured is a commented default in the config, and each camera prim records where its pose came from, so an estimate never passes for a measurement.

Status

Running around the clock as services with health checks: both cameras, detection, tracking, floor mapping, history, the 3D and 2D twins, layout editor and calibration tool. In progress: the custom damage detector (damage alerts stay muted until it ships, so today the cameras track people only) and the second camera’s calibration. The Kit extension’s layer hot-swap is verified in plain OpenUSD but hasn’t yet run inside Kit on the RTX workstation. Next: Omniverse Replicator on the same stage to synthesize labeled frames of damage the real footage rarely shows.

YOLOv8 · MemryX · ONNX Runtime · OpenCV · OpenUSD · three.js · Omniverse Kit · Flask · SQLite · systemd · Label Studio · Modbus Internal Contec project.

Contec Americas2026

A CCTV inference server built to a price

A rack-mount AI server that watches dealership CCTV in real time for vehicles and people, designed for a video-analytics partner under a fixed per-unit cost ceiling.

Method

Constraints first, in order: chassis, then GPU class, then power budget, then cooling. Each open item tracked as either a blocker or an optimization, in a workbook with a live-formula BOM, three configurations compared, site infrastructure, and power and thermal budgets.

What the constraints decided

• Consumer GPU licenses forbid commercial fleet use, so only professional data-center GPUs qualify: a passive, slot-powered card.
• A Contec motherboard as the anchor, with an integrated GPU kept for decoding many video streams and the CPU power-capped to stay within its temperature limit in a 2U chassis with the chosen cooler.
• Surveillance-rated drives and a pure sine-wave UPS, which the server’s active-PFC power supply needs.

Status

The BOM is within 1% of the target. Two blockers remain before any purchase order: the camera count and frame rate, which decide whether a GPU is needed at all, and written confirmation from the board vendor that the x16 slot delivers its full 75 W.

Trade studies · BOM · Power & thermal budgets · NVIDIA data-center GPUs · Ubuntu Proprietary work; the customer isn’t named.

Contec Americas2025 – present

Other Contec work

• Seismic sensor node Prototype

  A full-stack sensor node for a government customer that locates sources of ground vibration: geophone or accelerometer into a 24-bit ADC, GNSS-disciplined timing so an array of nodes can locate sources by time difference of arrival, STA/LTA event triggering, LTE Cat-M1 backhaul, and LiFePO4 with solar power, for Florida heat, humidity and a high water table.

• AI-ready small-form-factor desktops

  I lead a three-tier line of compact AI desktops (Standard, Pro, Max), managed in Arena PLM.

• AI over KVM In progress

  KVM-over-IP on a Raspberry Pi CM4 or CM5 with an HDMI-to-CSI capture board, built around an agent loop: it captures the screen as JPEG frames, an AI model decides, and the device types and clicks.

• Isolated engineering lab

  A private-subnet lab for CI/CD, embedded and IoT work, self-hosted services and network R&D, with its own internal DNS zone, subdomain routing behind a reverse proxy, and an 18U rolling rack laid out unit by unit.

• Embedded World North America 2026

  The two kiosk screens on Contec’s booth in Anaheim, plus a site for the team. Each kiosk is one self-contained HTML page that needs no network, because show Wi-Fi can’t be trusted. The two run at different speeds and start 4.2 seconds apart, so they never show their call to action at the same moment.

Proprietary work, described in general terms.

E4Phoenix Motors · Founder2022 – 2024

Electric powertrains for legacy vehicles

A small business I started after college, converting vehicles from many manufacturers and decades to road-legal electric powertrains.

Problem

Each platform was a different integration problem: a different manufacturer, a different decade, and the same requirement to be road-legal when finished.

Platforms

• 1990 Honda Transalp, a dual-sport motorcycle
• 1992 Jeep
• 2011 Volvo XC60
• Electric office trailer: a working office built into a trailer, with the battery bank under the floor, inverters, HVAC, and a generator to back it up

What I did

Defined the electrical architecture, powertrain interface specifications and compliance requirements. Integrated battery systems, motor controllers and the vehicle CAN networks.

Verification

Wrote the powertrain validation test procedures and coordinated field testing for performance, safety and compliance.

Why I started it

To pay off my student loans after graduating, using what my degrees taught me on real vehicles. It became my most hands-on integration work.

Electrical architecture · Interface specs · CAN · Battery & motor control · Inverters & HVAC · Test procedures · Compliance

E9Personal project2000 Kawasaki ZR-750F

From ashes: an electric motorcycle

My 2000 Kawasaki ZR-750F caught fire and burned down to the frame. Instead of scrapping it, I stripped what was left and rebuilt it as an electric motorcycle. It's now registered, insured and road-legal.

Problem

Turn a fire-gutted motorcycle into a road-legal electric one, with every electronic system on it new.

What I built

A 30 kW-peak BLDC hub motor on a 96 V-class controller, fed by an approximately 10 kWh pack of large prismatic lithium-ion cells in a 24S1P configuration (about 86 V nominal, 100.8 V full). An earlier pack of 18650 cells, 20S20P and about 3.6 kWh, was good for about 12 miles. The first version, my college proof of concept, ran a brushed DC motor on a bought controller and a 20S pack. After graduation I rebuilt it and designed the motor controller, battery management system, charger, CAN network and speedometer myself. It charges over J1772 and DC fast-charges over CCS1: DC fast chargers can't go as low as the pack's voltage, so an isolated step-down stage takes the station's output (up to 400 V) down to the pack's 100.8 V. A full CCS1 charge has worked at a public ChargePoint station.

Outcome

Measured top speed around 180 km/h (about 110 mph) and roughly 60 miles of range, depending on riding. Registered, insured and road-legal. Since an EV has no use for an exhaust pipe, mine blows bubbles instead: a bubble machine I designed, now patent pending.

Why it burned

A fuel leak on the original gasoline engine, most likely ignited at a cracked intake manifold. The fire had nothing to do with the conversion, which came after.

Verification

The bike’s requirements are under change control in Doorstop, each with a verification method and traced to its evidence. Closed and open, as they stand:

• Top speed and range, measured on the road: about 180 km/h against a 113 km/h (70 mph) requirement, and about 60 miles against 50.
• BMS balance resistors read 114.5 °C on a thermal camera against an 85 °C limit. I logged it as a nonconformance, reworked the board and re-tested it at 69 °C.
• A load test into a finned resistor bank with an E-stop in the loop, on the earlier 18650 pack.
• Open: the dash takes 28 s from key-on to live speed against a 3 s requirement, so it stays an open nonconformance until it’s reworked.
• Open: the move to the 24S1P pack means its balancing and load tests have to be re-run, and the CCS1 charge needs a filed record before it counts as verified.

College build, 2018–2022: design work

College build: how the pack evolved, 2019–2022

Electronics, harness and busbars

On the road, and the bubble exhaust (patent pending)

E3Open source · AGPL-3.02026

Shell:B, a local-first multi-agent workstation

A multi-agent AI environment that runs on your own hardware: local models through Ollama, code in a sealed sandbox, and a memory the owner can audit. Cloud models are opt-in, never the default.

Problem

Agents that write and run code and read untrusted web pages are a containment problem. The goal: a capable workstation where nothing leaves the machine unless the owner turns it on.

Containment

• Code runs in a Docker container with no network, every Linux capability dropped, a read-only root, resource limits and a hard time limit. Each conversation gets its own working folder.
• Text from web pages, email, feeds and webhooks is fenced off as untrusted data, and web fetches can’t reach local or private addresses, checked again on every redirect.
• Agents use stored secrets by name without ever seeing them: encrypted, limited to allowed hosts, approved per use and logged.
• The scouting agent that scrapes pages can’t search past conversations, so an injected prompt has less to reach.

Reversible by design

• Shell:B can change its own code, but only on a copy: checks run, I approve the diff, and a failed restart rolls back automatically.
• Memory learns only from the owner’s own words, can wait for review, and a correction retires the old entry instead of deleting it. Long chats get summarized, but nothing is deleted.
• Risky actions wait on an approval card; plan mode is read-only, enforced at the tool level.

Sharing safely

• Each guest gets their own network-isolated container behind a separate gateway, signing in with a password plus TOTP or a passkey.
• A public API and MCP server use hashed keys with per-key rate limits and daily quotas, and token use is metered per agent and model.
• Model calls can overflow to other machines I own; incognito and guest traffic stays local.

How it’s built

Python 3.12 and FastAPI on the back end, React 19 and TypeScript on the front, SQLite with full-text search over past chats and embeddings for memory. Written largely with AI coding agents, including Shell:B’s own; I review and verify what they produce.

Why it’s here

It’s where I practice AI-assisted engineering in public, and the design follows the same ideas as a hazard control: contain what can fail, give each part only the access it needs, keep changes reversible.

Python · FastAPI · TypeScript · React · Vite · Tailwind · Docker · Ollama · SQLite Source on GitHub ↗

E5Florida Institute of Technology

Two Best in Show competition entries

Two student team projects, each named Best in Show for Aerospace Engineering at Florida Tech’s Northrop Grumman Engineering & Science Student Design Showcase.

• RotoCop Best in Show 2018

  Northrop Grumman RotoCop Counter-Criminal Design Competition. Our entry was a hexacopter for aerial surveillance, powered from the ground through a tether so its flight time wasn’t limited by a battery. I was the team’s automation lead and built the entire ground station: it fed power up the tether, received the video feed, and ran the drone’s automation. One small part of it is public on GitHub: the touchscreen controller, Arduino firmware that turns a TFT touch panel into a USB keyboard with configurable on-screen buttons, a small graphics library for it (C/C++), and a C# desktop editor for the button layouts.

  Firmware ↗ Controller sketch ↗ Layout editor ↗

  

• NASA Robotic Mining Competition Best in Show 2019

  Florida Tech’s entry in NASA’s Robotic Mining Competition: PHRED, an excavation robot that digs regolith simulant with a bucket ladder and carries it in a hopper. I was the project manager for the 12-person team and ran the project end to end. PHRED was built for the 2020 competition, which NASA cancelled because of COVID-19.

  

  

  

• Location-aware E-ink parking decal

  A 4.2-inch e-paper parking decal that changes what it shows based on my location. An ESP32 reads a GPS/GNSS receiver and switches the display to the permit for wherever the car is parked. The permit shown is expired.

  

• Earlier embedded tools

  A .NET library for writing Arduino code in C#, and a Raspberry Pi equipment logger in Python built for Florida Tech Video Productions.

  ArduiNet ↗ pilog ↗

Personal project2026 · In design

QP-1: a VTOL drone run as a vehicle program

A QuadPlane (vertical takeoff, fixed-wing cruise) on a Holybro Pixhawk 4 Mini, with cellular command and control for flights beyond radio range and FAA Remote ID. I’m running it as a miniature flight-vehicle program with a public digital thread: concept of operations, system model, requirements, simulation, safety analysis, readiness review, then flight test. It is in design and build. Nothing here has flown yet, and every figure says whether its numbers come from analysis or simulation.

What exists

• A concept of operations in INCOSE / NASA SE Handbook style: mission phases with entry and exit conditions, operating limits under FAA Part 107 and the airspace around the Space Coast (Melbourne’s Class C, the Cape’s restricted areas, launch TFRs), nine off-nominal scenarios each mapped to the ArduPilot failsafe parameters that implement it, 15 top-level requirements with a verification method each, and 18 recorded baseline decisions.
• ArduPilot software-in-the-loop on a DGX Spark flying the reference mission end to end: VTOL takeoff to 30 m, transition, a 500 m box, return and a vertical landing. Transition takes 9.5 s, the aircraft lands 6 to 8 cm from the pad, and repeat runs agree to within 0.5 s.
• A simulated recovery in the shape of a New Glenn booster landing: launch from the shore, fly 1.2 km out to sea, then land on a 10 m deck on a moving uncrewed ship. It uses ArduPilot SITL’s ship simulator and the stock plane_ship_landing Lua applet, flown with ArduPilot’s generic built-in QuadPlane model, not QP-1’s own parameters. In a 62-run Monte Carlo sweep (wind 0 to 10 m/s from any direction, turbulence up to 2 m/s, ship speed 2 to 6 m/s, a different noise seed each run), all 62 landed on the deck (95 % confidence interval 94 to 100 %), and 95 % of them touched down within 1.15 m of the landing point. This is simulation only: the deck doesn’t pitch, roll or heave, and there is no ship airwake.
• A design point sized before buying parts: 4.35 kg estimated against a 4.5 kg target, about 580 W to hover against 155 W to cruise, and about 50 minutes of estimated fixed-wing endurance.

What the analysis turned up

• ArduPilot sets one action for both RC loss and ground-station loss. Beyond RC range the aircraft has to ignore a lost RC link, but it has to come home if every link is gone, and parameters alone can’t say both. A short Lua check on the flight controller does it, so it still works if the companion computer or the modem is what failed.
• The first simulated landing overshot the pad because the final approach was too short, and it cost 57 % more hover time. Hover is 70 % of the reference mission’s energy, so approach length became a planning rule: at least 1.5× the stopping distance.
• Ten more ship runs outside that envelope found a failure mode. Every run with the ship faster than the VTOL speed limit (Q_WP_SPD, 7 m/s) failed, six out of six. The aircraft either hovered behind the ship indefinitely or kept descending and landed in the sea astern, because the landing descent is cleared once and never re-checked. Raising the limit to 12 m/s landed all six on the deck. The rule is a speed limit above the fastest deck the mission allows, plus an abort-and-climb check that the stock landing script doesn’t have.
• The Pixhawk 4 Mini’s serial ports are all taken by the companion computer, GPS and RC receiver. Remote ID went on the CAN bus, and a second GPS and ADS-B In are deferred until they can go there too.

Status

In design and build; no flights. Next: a SysML model of the vehicle, the requirements in a requirements-management tool, SITL re-flown with QP-1’s own parameters over an emulated cellular link, STPA and FMECA, and a flight-readiness review before the first hover.

ArduPilot QuadPlane · SITL · MAVLink · Lua · ExpressLRS · LTE · Tailscale · Remote ID · Part 107 · Python · matplotlib Personal project. Figures show analysis and simulation, not flight data.

Personal projectsIn progress

Current builds

• Field-engineering cyberdeck

  A handheld built around a Raspberry Pi CM5, with three displays (a 4-inch OLED, an e-ink strip and an OLED activity strip), a split ortholinear keyboard, two isolated CAN FD ports, a battery tester using electrochemical impedance spectroscopy, and swappable expansion cartridges. Designed in EasyEDA Pro, boards made by JLCPCB.

• VTOL drone

  An ArduPilot QuadPlane (vertical takeoff, fixed-wing cruise) on a Holybro Pixhawk 4 Mini, with a cellular command link for flights beyond radio range, FAA Remote ID, and MAVLink routed between the flight controller, a companion computer and the ground. Details

• BARK, a quadruped robot

  A dog-sized four-legged robot built from scratch for dynamic-locomotion research, on off-the-shelf quasi-direct-drive actuators and a parts budget under $3,000. Early stage.