Ondyra · industrial systems engineering
Your machines know more than they show.
Ondyra connects industrial equipment to software. We fit the sensors, write the control logic and build the screens that show what a machine is doing — so you can act on it.
Scoped engineering projects for manufacturers, machine builders and labs
The illustration is a live, simulated miniature of an industrial system: a pump fills a tank, sensors measure it, a controller cabinet keeps the level between two limits, and a screen on a mast shows the level to an operator.
Sensing the unseen
From a machine you go and check, to one that reports for itself.
The same small system, four times: as most equipment is today, then with each layer of engineering Ondyra adds. The miniature is simulated; the engineering is the real thing.
The pump runs and the tank fills. But the level, the temperature and the flow exist only at the machine. Someone walks over, reads a gauge and writes it down — and problems are noticed once they are already problems.
So:Most of our conversations start here.
The right sensors, fitted and wired: level, flow, pressure, temperature. Each becomes an electrical signal a controller can read — with its range defined, and a broken wire detected as a fault rather than read as a value.
You get:Readings you can trust, without a clipboard.
A controller — a PLC or a microcontroller, depending on the job — runs the logic: start the pump at 40 %, stop it at 70 %, and stop safely if the level sensor fails. What happens when something breaks is decided first.
You get:The routine runs itself, and fails safe.
The controller shares its data over a standard industrial protocol, and a screen shows the level, the pump, alarms and history — in the control room, the office or a browser. If the link drops, the screen says so instead of showing old numbers as if they were live.
You get:You see what is happening without walking over — and you see it first.
If the link drops, the machine keeps working — and the screen says so, instead of showing old numbers as if they were live.
Simulated · the miniature unplugs its own network cable as you scroll past.
What you can commission
See it. Connect it. Automate it. Measure it.
Four kinds of project that make machines measurable, connected, controllable — and understood by the people who run them.
Each one starts with one machine and one well-defined result, so you can judge the value before committing to more.
Machine data & monitoring
“We only find out how a machine was running when it stops.”
What we engineer
We fit — or tap into — the sensors that matter, acquire the data, and build the screen that shows live values, trends and alarms: on the shop floor, in the office or in a browser.
What you get
- Live readings instead of rounds with a clipboard
- Trends that show a problem developing, not just the breakdown
- A history to compare against after every change
A first project: One machine, a handful of signals, one screen.Not plant-wide MES or ERP.
Discuss thisConnectivity & integration
“The data is in the machine. Getting it into our software means someone typing it in.”
What we engineer
We bridge the machine and your software in the protocol each side speaks — Modbus, OPC UA or MQTT — with a documented register map, data types and timeout behaviour.
What you get
- Data that moves by itself, with its units and meaning intact
- A link that says when it is down, instead of showing old values
- An interface written down, so the next change is not guesswork
A first project: One device, one data path, tested end to end.Not a replacement for your control system.
Discuss thisAutomation & control prototypes
“Someone does this step by hand, every time — and we are not sure automating it will pay.”
What we engineer
We write the control logic on a PLC or a microcontroller — the sequence, the interlocks, and the safe state for every failure — and prove it on a bench before it touches the machine.
What you get
- A working prototype to judge before committing more
- Every fault case tested: what happens when a sensor or a link fails
- A specification you can take into production
A first project: One sequence on a bench, with its fault cases.Not certified safety functions (SIL) or complete lines.
Discuss thisInstrumentation & test benches
“We need a number nobody measures yet — and we need to be able to trust it.”
What we engineer
We design the measurement chain — sensor, signal conditioning, acquisition and the software that records it — and check it against a reference before anyone relies on it.
What you get
- Data with a known range, sampling rate and uncertainty
- Raw and processed signals recorded side by side
- A setup documented well enough to repeat
A first project: One measurement, validated against a reference.Not accredited calibration.
Discuss this
Machine data & monitoring · an illustration of the kind of system, not a client project
Not sure which one fits? Start with the machine.
Most projects begin as a conversation about one piece of equipment and what you wish you knew about it. Ondyra is early-stage: these are the kinds of work taken on, not a catalogue of finished client projects.
Three situations you may recognise.
Different equipment, the same kind of gap: information that exists at the machine but reaches nobody in time.
Illustrative miniatures of kinds of systems — not past client projects.
Output and rejects are tallied at the end of the shift — if anyone has time.
So:Throughput and rejects visible as they happen, not the next morning.
Service: See itIllustrative scenario, not a delivered project.
How a first project runs
From one problem to a working system.
A project can begin with one clearly defined problem, move through a focused prototype, and produce something you can evaluate before committing to anything larger.
One illustrative project, followed from start to finish. Not a client project.
Illustrative project · values are examples
Understand
We look at the equipment and the problem together — here, a pump motor whose bearing temperature someone checks by hand once a shift. What should be measured, how often, and who needs to see it?
- Why it matters
- The right solution depends on the question. Measuring the wrong thing precisely is still the wrong thing.
- What you can expect
- A short written summary of the problem, the signals involved and what a useful result would look like.
Design
The measurement chain is drawn and written down: a sensor on the bearing, a controller beside the machine, a network link, a screen — with ranges, update rate and an alarm limit.
- Why it matters
- Decisions made on paper are cheap to change. They also become the criteria the prototype is tested against.
- What you can expect
- A scope with a diagram, a signal list and acceptance criteria — and a plain statement of what is out of scope.
Prototype
The design becomes hardware and software on a bench: the sensor is fitted, the controller reads it and the screen starts to show a live trend.
- Why it matters
- A working proof of concept answers questions that discussion cannot, and exposes problems while they are still small.
- What you can expect
- A running prototype with real readings that you can see and question, before any larger commitment.
Validate
Each criterion from the design is checked: the reading against a reference thermometer, the alarm at its limit, what the screen shows when the link is lost.
- Why it matters
- “It seems to work” is not a result. A check against criteria agreed in advance is.
- What you can expect
- A test record: what was checked, how, and the outcome. A bench test against your criteria — not a certification.
Integrate
The tested system is installed where the work is done: the sensor on the motor, the controller beside it, the data on a screen in the office.
- Why it matters
- The value appears only when the pieces work together, at the machine and for the people who use it.
- What you can expect
- A working, documented system — wiring diagram, I/O list, register map, test record and operating notes — that you can evaluate before deciding on anything larger.
One defined problem. One focused prototype. A result you can judge before you commit to more.
Where Ondyra stands today.
Plainly, so you can judge the risk: the engineering on this site is real and documented; the company is new. A first project is scoped so that it is worth doing on its own.
- Exists
- This website, and two simulations that run in your browser: a level-control system and a vibration-analysis experiment.
- Not yet
- Client projects, commercial installations, certifications or a team. Ondyra is founded by an Electrical and Computer Engineering student in Portugal.
Have a machine, process or integration challenge?
Tell us what equipment you are working with, and what you need to measure, monitor, connect or control.
Opens your email app with a short brief about “see data from a machine” to fill in.
What helps us understand it
- The equipment or process, and roughly how old it is
- What you would like to measure, see, connect or automate
- Controllers, instruments or protocols already in place, if you know them
- A photo of the machine or its control panel, if you can share one
What happens next
- You write to the founder directly — no sales team in between.
- You get questions back, or a first view of whether and how Ondyra can help. If it is not a good fit, you are told so.
- If it is, a small first scope is proposed in writing before any work starts.
Especially if you are…
- Small and medium manufacturerswith machines whose data nobody sees, or tasks still done by hand.
- Machine buildersadding monitoring, connectivity or a test bench to their equipment.
- Laboratoriesthat need a measurement chain or data acquisition for a rig.
- Industrial integratorswho need a well-defined piece of instrumentation, communications or HMI work.