First of all, it is necessary to know what the customer’s expectations / requirements are. Without that, any electronics development is bound to become costly. If the requirements are not yet written down on paper, that will be the first step. Both the customer and the developer need to think carefully about the consequences of adding or omitting any requirement. Both may lead to additional work.
The functional requirements describe at an abstract level what the solution should do.
For example, for a single phase power analyser:
- Measure the AC voltage and current of 1 Phase (range 85 - 270Vac)
- Determination of
- the power
- the power factor (cos-Phi)
- the energy (kWh)
- Logging of Vrms, Irms, Pre, Pim per line cycle (20ms or 16.67ms)
- Readout via Ethernet
The Ethernet port will accept DHCP and the logging sends data as UDP over Ethernet.
If the customer has an explanation in detail, e.g. about certain algorithms, this will also be described here.
This describes what electronics is required, such as connections, possibly with detailed information about ranges and accuracies, the connector or safety issues.
In our example:
- 1 Single-phase input
- 1 Single-phase output
- 1 RJ45 Ethernet connection
Any device placed on the market in the EU or other countries will have to comply with a number of standards.
For Europe, the CE Directive 2014/30/EU applies. For electronics, this actually always means that EMC standards must be met.
Depending on the application, other standards also apply, e.g. with regard to safety.
Just looking at the electronics does not mean that the entire product complies. Eventually the end product has to comply, and the manufacturer (usually you) issues a certificate of conformity.
For the electronics, it has to be determined which standards are applicable, which may have an influence on the design. The developer can then pay attention to this during the design.
This is the phase in which the design is made. This can be subdivided into a more detailed analysis, the overall design, design details and implementation.
Based on the required standards, the risks are mapped out and an FMEA1 (Failure Mode Effect Analysis) is made.
This does not always have to be very formal, but it is good to have thought beforehand about what needs to be done. when something goes wrong.
In our example:
Failure Effect Severity [0-9] Ethernet disconnect UDP Data not sent 0 Phase wire open No load current 1
The design can now be optimised so that the ‘Severity’ is sufficiently low.
Safety aspects can also be made visible via an FMEA. Often there are also standards with which the device must comply that set special safety requirements.
If the analyses are in order, the overall draft will follow. A layout will be made of the necessary blocks and examined whether the functional block distribution is logical and has no adverse side effects. The safety and possible failures can also be taken into account here.
Sensors often require special processing. With industrial sensors, this processing is already built in, and that can be reflected in the price. By connecting the sensor directly to its own electronics, a reduction in costs is achieved.
What applies to sensors also applies to actuators.
Sometimes the use of control electronics is beneficial, instead of e.g. a relay.
Often it gives more possibilities to optimize the actuator.
Take, for example, a device with a number of DC motors. The control can be done with a relay, even bidirectional.
But with a transistor control with underlying software a soft-start and soft-stop can be realised. This cannot be done with a relay.
Now the ideas from the overall design are being turned into reality.
Schematics are drawn and printed circuit boards are designed. The printed circuit boards are assembled so that the
embedded software (firmware) can be tested.
Depending on the application, provision must be made for updating the firmware. For applications with embedded communication (wired or wireless), this saves a lot of time in use, because the update can then take place remotely.
Electronics Qualification phase
Qualification is verifying that all requirements are actually met in the prototype, and that everything is working correctly.
A lot of attention has to be paid to out-of-range and/or error situations.
All measurements are documented, so that it can be seen later whether something has been tested, and what the result was.
Ultimately, the electronics must also be built in something. For the wiring to the connectors and the height of parts a check on the mechanical fit is needed. This may lead to minor adjustments. If the design has already been ‘fitted’ on the computer via 3D drawings, the chance of adjustments is already smaller.
Next, the customer will be involved in the process again. He must now make sure that the product
meets the requirements that have been laid down.
Many customers are not as sharp as they should be in this respect. They think that the developer should have done his job well, but forget that they are the experts in their field, and the developer will mainly stick to the requirements. Surely there can be a difference in perception.
Often the physical device (the customer’s device) is brought to life for the first time when the electronics are connected. Then it may turn out that there are all kinds of small points where further fine-tuning is required. This can be timing or compensating for mechanical effects.
An extensive endurance test under varying conditions is also highly desirable.
The introduction of error situations is an important phase in the acceptance tests. By simulating as many error situations as possible it can checked whether the electronics are handling them correctly. A developer will mainly test the ’normal’ situations during development, and to a lesser extent the error situations.
If the prototype did not need any modifications, production can often be started immediately. Otherwise, it is wise to make another pre-production. or a 0 series. Such a 0-series is then a limited number e.g. 10 to 25. If something has gone seriously wrong after all, the damage is at least manageable.If 1,000 or 5,000 PCBs have already been produced, the costs of repair or, worse still, replacement are very high.
With every production, the result must be tested. After all, mistakes may have been made, such as fitting an incorrect component. But more often it concerns soldering errors.Then a component has not been soldered properly, or a short circuit of soldering tin has occurred. There are two levels of testing:
- Functional test
- Specification test
In many cases, a Functional Test is sufficient, but for devices that go to faraway countries, and where service and
repairs are expensive a test system, which also tests the specifications, can be cheaper.
Testing to specification means, for example, measuring the frequency characteristic of analogue inputs. With only a functional test, a faulty component in this path may not become visible. This increases the damage.
For production with larger numbers a penbed tester will often be made. With this, automatic tests are carried out.
Often the test electronics are more extensive and complicated than the produced product.
Production will involve weighing up whether to produce quickly or at a low price, and also whether and how many products will be produced for what period of time. It is also possible to put components with a long delivery time on stock.
With a short phone call you already know.
FMEA - Failure Mode Effect Analysis
An overview of faults (both operating faults and defects) with the chance of occurrence and an indication of how severe this is. Faults that can occur more frequently and have serious consequences must then be dealt with technically, so that the seriousness decreases. ↩︎