"There are two problems to solve when conquering space: gravity and the paperwork. We could have handled gravity."
Wernher von Braun
Anyone working as an engineer in development will understand the humor of Wernher von Braun's quote. It seems as if the amount of documentation is constantly increasing, and with it the part of the work that many engineers dislike. However, the discomfort with documents often stems from the lack of clarity about what should be included in the specification. In this article, I would like to provide an overview of the ingredients for a good hardware specification.
The hardware specification is the input document for hardware development and schematic creation. It's therefore quite surprising when, in projects, the schematic is created before the specification. However, this document is important not only for the schematic creator. A hardware specification is required for those who are supposed to review the schematic. How can you verify whether someone has developed a useful circuit if you don't know what it's intended for or how it's constructed?
The hardware specification describes the purpose of the module, its design and structure, what parts of the module are (component boundaries), and what interfaces it has. Furthermore, the hardware specification contains the requirements for the module. These requirements are verified within the framework of a hardware test specification.
The hardware specification enables the system architect to verify whether the hardware fits into the system and meets the system requirements. This allows the hardware developer to focus on their component and develop one piece of the overall system puzzle.
Don't put off the hardware specification! You need the information from the specification to work efficiently. The main effort lies not in the hardware specification, but in the schematic design and hardware testing.
Contents of a hardware specification
The following section will specifically address the content of a hardware specification. Consider this content as a suggestion and adapt it to your needs. You may have specifications from your QM (quality management) department or specific technical aspects that you want to consider. It's not possible to define a generally applicable procedure at this point.
Purpose and scope
Purpose and scope may sound unspectacular and unimportant at first. But it isn't. Especially when the document is being read by others, this is often the starting point. People expect to know what the document is about and what scope it covers. Readers of the document can be testing laboratories, notified bodies, the customer, or other people in the project. Therefore, it is important to fill out this section of the document properly. It would be a shame if the first impression suffered as a result.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Don't reinvent the wheel every time. It's a good idea to integrate a pre-written text into your template and enter explicit instructions for the creator to complete. This way, you won't have to overthink things and will have a customized introduction to the document. Consult with your QM manager about this.
Block diagram
The block diagram is a perfect introduction to the functionality of an electronic assembly. Here, you define the component boundaries of the hardware and answer the question: What belongs to my component and how is it structured? The interfaces that arise at the component boundaries are particularly important. These interfaces must be coordinated with other project participants. This is where most errors occur. Therefore, it is very important to document the assembly interfaces well and distribute this information to those who have an interest in these interfaces.
Finally, it's essential to define the modules of the assembly and the interfaces between them in the block diagram. Therefore, for each component and each interface, describe its purpose and how it functions.
The block diagram clarifies the following questions:
- Where is the limit of my hardware (what is inside and what is outside?)
- What are the interfaces of my assembly?
- Which modules does my assembly have (with description)?
- What interfaces are there between the modules (with description)?
Design and mechanical structure
Here, you describe the dimensions and contour of the assembly. You can describe the location of the connectors or components with fixed positions (e.g., buttons, LEDs, or large components). You can also create an initial placement here. Where will the power supply go, and where will the microprocessor? At this point, it's sufficient to provide a rough layout. This doesn't have to be done with a CAD tool. A simple sketch will suffice.
With this design, you can prevent interference on the circuit board early on through spatial separation and clever layout. Electromagnetic compatibility (EMC) plays a role here. Inappropriate placement and the formation of loops can cause EMC interference. You can already consider the number of layers on your board and the necessary EMC measures.
What should you define here?
- Dimensions and contour of the circuit board
- Position of connectors and other fixed components (LEDs, buttons)
- Spatial distribution of the components (placement)
- Distribution of ground and supply voltages on the circuit board
- EMC measures
- Measures to meet mechanical requirements (shock and vibration)
- Position of antennas for radio transmission
- Position of components that can generate heat
At this point, close cooperation between the hardware and mechanical developers is necessary.
Requirements for the assembly
Each module has requirements. Otherwise, the module wouldn't be necessary. The system requirements are broken down to the module itself. Create a structure (subsections) based on your architecture (e.g., power supply, microcontroller, HMI – Human Machine Interface, sensor xyz, etc.). Distribute the requirements among the respective circuit modules.
When creating the requirements, there are a few points to consider. These are the requirements for the requirements, so to speak. The table below shows the most important properties that the requirements should fulfill.
| Characteristic | Explanation |
| Testable | Every requirement is tested. If you can't think of a meaningful test case, then the requirement isn't good. |
| Complete | Make sure you don't forget anything. A lot of information is stored in your head. Put it down on paper. This will improve the depth of the test. |
| Relevant | Only formulate requirements that are relevant to the component or system. It doesn't matter which components you use or how the implementation actually looks. |
| Consistent | Avoid contradictions in requirements. Make sure the requirements fit together. |
| Clearly | Formulate the requirements clearly so that there is no room for interpretation. |
| Context-free | Formulate the requirement so that it can be understood without context. It's not good, for example, if the requirement can only be understood if you know which chapter it's in. The requirement should be understandable on its own. |
| Atomic | Keep the requirements short and concise. Don't try to combine multiple requirements into one. This will make the requirements more understandable, readable, and easier to test. |
Have a colleague read through the specification and get feedback. Testers, in particular, are very good at checking whether requirements are well-written. Involve the software colleague if your component contains software.
To formulate the requirements, it is useful to use a sentence template that can be used again and again.
Examples of requirements
- The module should be able to operate from 6.0V to 12.4V.
- The module may have a maximum current consumption of 500mA.
- The module should activate the green power LED when the mains supply is applied.
- The module should be able to activate the power LED via the microprocessor.
- The module should switch the output port z depending on the inputs port A and port B according to the truth table below.
| Port A | Port B | Port Z |
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
Interfaces
Errors usually occur at the interfaces. Therefore, document the interfaces thoroughly and check them carefully during the review. It's a good idea to create a table for each interface. Include a picture of the connector to avoid confusion. If necessary, you can also draw the circuit board to accurately show the orientation.
| Pin | Signal name | Direction | Description |
| 1 | GND | Input | mass |
| 2 | Vcc | Input | Supply voltage UIn = 4.0V – 12.4V Imax = 500mA |
| 3 | HOST_UART_RX | Input | UART interface to the host 9600 baud, 8n1 |
| 4 | HOST_UART_TX | output | |
| 5 | HOST_ENABLE | Input | Signal to activate/deactivate the module 0: Module inactive 1: Module active(IH = 2.4V; IL = 0.4V) |
| 6 | GND | Input | mass |
The pinouts of microprocessors can also be represented using the same scheme as in the table above. This information is very valuable for software developers.
Power supply
Document how the component's power supply is implemented. Consider all relevant power paths and document the voltage ranges, power consumption, and current peaks. Include the timing behavior during power-on and power-off, as well as the behavior during voltage drops (power up, power down, power fail).
Galvanic isolation and regulatory requirements play a key role in medical devices. Therefore, incorporate this information into the hardware specifications.
Specify which fuses you are using and how they are dimensioned.
Self-test and monitoring
Consider self-tests and runtime monitoring. Components can fail or malfunction. Therefore, it's important to consider which signals should be monitored and how to locate the errors. A hardware FMEA involves a structured review of the circuit diagram and determining which errors can occur and their resulting effects. Measures are then defined to eliminate any unacceptable effects. However, it's a good idea to consider this and develop a concept before conducting the FMEA.
Control of signals
When controlling signals, it is important to create a timing diagram. This makes it clear which signals are involved in the control or monitoring process and what their temporal behavior looks like. It is a significant simplification for the software developer to be able to see which signals need to be switched, how, and when to perform an action. When examining signals, weaknesses or constellations that need to be considered often become apparent.
Pay particular attention to fast signals for controlling memories or displays and to signals that are delayed by galvanic isolation or other circuits.
What is Detailed Design in Hardware?
Detailed design is about documenting the schematic and the decisions made. Calculations and concepts are entered here, and decisions are justified. It's not necessary to work with keys and requirements here. This is your document to document what you were thinking when creating the schematic. It also provides valuable input for colleagues who are reviewing the schematic or who may be required to continue the work.
Make it a habit to update and maintain the hardware design description promptly. Enter the design decisions here in a way that is understandable for others.
What should be considered when testing?
There are two useful approaches to testing. First, you check whether the hardware meets the requirements. You check against the test specification you created based on the hardware requirements. Second, you check your hardware to see if it is correctly dimensioned. The basis for this is the schematic. The reason for this approach is that it's quite possible that you meet all the requirements, but the board is incorrectly dimensioned or component properties have been overlooked.
A few more tips for your hardware specification
Finally, I would like to give you a few tips that can improve the quality of your specification.
Avoid describing information about the system at the component level. To put it bluntly, it might even matter to you which system your component is installed in, as long as the requirements still apply. Therefore, write only about the component. This allows not only your component but also the documentation to be reused.
The architecture of your component is represented in the block diagram. This architecture must be a central theme throughout the entire project. The architecture must be easily recognizable when reviewing the schematic. The components should appear in the test specification and test reports. Finally, the architecture should appear in the schedule. And by that, I don't mean "create architecture" as an item. No, there should be a test report for each module of your component and for each interface. At the very least, you should consider which components or interfaces you want to create one for, and which ones don't. You may want to conduct preliminary tests on individual modules. These can be found in the schedule.
Conduct reviews to verify the hardware specifications. Invite the software developer, if the component has software on it. They can provide valuable input. In particular, review the interface descriptions carefully. Errors that occur at the interfaces are often particularly destructive and costly. Don't forget the interface to the software (microcontroller). This is where the signal name, direction, and meaning of each pin should be defined.
Document changes to the document in a change history. This shows who changed what and when. Errors often arise when maintaining documents and the product. Therefore, always keep a record of what has changed.
I welcome feedback and would love for you to contact me. Feel free to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you would recommend it.
Best regards
Goran Madzar