About Herder Elektronische Systemen
Engineering systems that can be understood, tested and trusted.
Herder Elektronische Systemen is a U.S.-based independent engineering practice in Michigan, focused on embedded controls, power electronics, real-time testing, technical recovery and AI-assisted engineering software for technical teams, laboratories, manufacturers and small industrial firms.
01 / Origins
A practice built from
engineering work.
Herder Elektronische Systemen grew from a working engineering test facility used for power electronics, embedded control, electric machines, instrumentation and real-time testing.
Development boards, power stages, motors, sensors, test equipment and experimental circuits became an environment for building complete systems. Hardware was connected to firmware, firmware to controls, controls to instrumentation and measurements back to design decisions.
That engineering test work established the practice's central method: follow the technical problem across the full system until the implementation, physical behavior and evidence agree.
As projects became larger, another problem became equally important. Engineering context was often scattered across source files, models, test data, schematics, archived revisions and incomplete documentation. Recovering the reasoning behind a project could become as difficult as building it.
That need led to work in technical recovery, evidence preservation and AI-assisted engineering software. SafeFileAI and SafeECADAI emerged from the need to keep engineering conclusions connected to the files, measurements and decisions that support them.
The engineering foundation
- Power-electronics prototyping
- Embedded control hardware
- Electric-machine test systems
- PCB development and bring-up
- Oscilloscopes, electronic loads and instrumentation
- Real-time control and automated data collection
- Hardware, firmware and model integration
02 / Integrated engineering
Engineering across
connected systems.
Herder Elektronische Systemen works across embedded software, electronics, controls, hardware and test because the behavior of a prototype rarely belongs to only one layer.
A control issue may originate in sensing, timing, power delivery or physical response. A firmware problem may appear only under real hardware conditions. A test result may depend as much on instrumentation and setup as on the design being evaluated.
The practice therefore treats hardware, firmware, models, communications and measurements as parts of one engineering system. The objective is to identify the relevant interfaces, establish what the evidence supports and leave a technical path that can be reviewed and continued.
03 / Technical foundation
A capability
profile.
Firmware architecture
State machines
Timing and interrupts
Field-oriented control
Real-time systems
Feedback integration
UART
SPI
I²C
Simulink
Python processing
Structured test data
Prototype bring-up
Sensors and actuators
Power-stage integration
Flyback development
Custom magnetics
Bench measurement
Automated data collection
Validation workflows
Technical reporting
Build reproduction
Evidence recovery
Technical documentation
Evidence-aware technical workflows
04 / Engineering principles
Evidence before
claims.
Good-fit engagements
Technical work with
enough substance.
The strongest fit includes:
- Embedded or control-system prototypes
- Incomplete or inherited engineering projects
- Firmware and hardware integration
- Test automation and instrumentation
- Power-electronics prototypes
- Design recovery and technical documentation
- Technically demanding early-stage product development
05 / Founder and engineering lead
Jonathan Hernandez
Jonathan Hernandez's work spans embedded control, power electronics, electric machines, real-time testing, instrumentation and engineering software.
His project experience includes permanent-magnet motor drives, field-oriented control, CAN-connected embedded platforms, PCB development, converter prototyping, automated data collection and recovery of complex technical repositories.
He founded Herder Elektronische Systemen to work on the interfaces that often determine whether a prototype can be understood, tested and continued.
A control problem may require inspecting the power stage. A firmware problem may originate in sensing or timing. A weak test result may come from instrumentation rather than the design itself. A project may appear complete but remain difficult to continue because its files, assumptions and evidence are disconnected.
The practice is built around hands-on investigation, measured validation, careful recovery and documentation that preserves what is known, what remains uncertain and what should happen next.
Start a technical discussion
Start with the
technical question.
Describe the system, its current stage, the problem you are trying to resolve and what evidence is available. Secure file exchange can follow the initial discussion.
Start a technical discussion →Or write directly: [email protected]