Difference between revisions of "Block Interface Design"
From EUDP
(→Why) |
|||
| (19 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
== What == | == What == | ||
| − | Block Interface Design | + | Block Interface Design is the process of developing one or more suited methods for connecting two or more modules in a system. |
| − | Interfaces | + | Interfaces between two (or more) blocks '''must''' be coherent (i.e. both implement the same interface, allowing interconnection). |
== How == | == How == | ||
| Line 9: | Line 9: | ||
'''Ingredients''' | '''Ingredients''' | ||
| − | + | Depending on the nature of the system-to-be, interface design requires several of the following inputs: | |
| − | *Block | + | *Block and component diagrams |
| − | *SW | + | *SW and electronics specification/requirements |
*Circuit board and/or sub-system specifications | *Circuit board and/or sub-system specifications | ||
*System specification | *System specification | ||
| Line 21: | Line 21: | ||
'''Process''' | '''Process''' | ||
| − | Interface design | + | Interface design is basically the process of iterating through all functional blocks in the system-to-be, assessing: |
| − | * | + | * Desired functionality |
| − | * | + | * Required information flow |
| − | * | + | * Suited standards for exchanging information, power, data, etc. |
| − | Thus by having a common understanding of the desired functionality, one can select suited interfaces | + | ====Interface Identification==== |
| + | |||
| + | Thus, by having a common understanding of the desired functionality, one can select suited interfaces that connect the blocks to be designed, being '''both''' HW and SW. | ||
| − | Again, if the | + | Again, if the interface design activities reveal that functionality has not been assigned in an optimal manner, smaller repartitioning (see [[Design Partitioning]]) might be necessary. This can allow for another, and perhaps even better, interface selection. |
| − | + | When you feel that the system interfaces have been identified and described, it is time to perform an Interface Analysis. | |
| − | + | ||
| − | + | ====Interface Analysis==== | |
| + | Interface analysis is a technique to verify that the inputs and outputs of the system-to-be are consistent with the defined signals, inputs, outputs and data of the rest of the system. In addition, the technique looks for inputs and outputs that do not connect with other elements of the system (missing items). | ||
| − | + | This analysis is '''vital''' every time you cooperate with other team members, other teams that develop parts of the system, or simply if you choose to interface a component "on the shelf". | |
| − | + | ||
| − | + | When performing an interface analysis for the architecture of your system, you want to focus on the following aspects: | |
| − | + | * '''Physical:''' | |
| + | **Check the number of pins on the device and make sure that it matches the number on the circuit board drawing. If pin assignments are defined, verify that they are consistent between the circuit board and the complex electronics specification. Also, check for pins that are undefined or floating. | ||
| + | * '''Power:''' | ||
| + | **Make sure that the correct voltages are applied to the power pins. Is the correct type of power (A/C, D/C) provided? Are the ground pins connected? What voltage levels (range) are acceptable for the input or output? What voltage is considered a "high" or a "low" for logic values? Are fan-in and fan-out requirements met? | ||
| + | * '''Signals:''' | ||
| + | **Verify that input signals match the output signals of other devices. Verify that every input signal comes from somewhere, and that every output signal is used by some other device. Verify that the types of signals are correct and consistent. Check timing requirements for the signals. | ||
| + | * '''Communications:''' | ||
| + | **If the component/block requires communication via a specified interface or data communication protocol, make sure that the communication requirements are fulfilled on both sides of the end comprising the interface. Check any defined messages or data for consistency across the interface. | ||
| + | * '''System level:''' | ||
| + | **Take a step back from the details and consider how the complex electronics work within the system. Look at the functions that the device must implement and consider whether the correct inputs are provided to the device. Will the device have enough information to perform its expected functions? Also look at the broader data and communication paths. Are there any bottlenecks that could affect the timing of data coming into the complex electronics or slow down any outputs on the way to other devices? How would failure of one part of the communication path affect the complex electronic device? | ||
| + | * '''Parameter ranges:''' | ||
| + | ** For SW blocks, be careful to analyse the required parameters to functions and define the valid range(s) for the data transferred to the function through the parameters. As part of the design specification, it is a good idea to have well-defined parameter ranges to program against. | ||
| + | * '''Function responses:''' | ||
| + | ** Define valid responses from the functions. In order to design other SW blocks, the response from a function call must be well-defined and known. | ||
| − | + | During design and realisation, the interface analysis should also be performed on the individual blocks in your design. Here, focus can be narrowed down to following: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | * '''Logical:''' | ||
| + | **Logical blocks take inputs, process them and produce outputs. Check the description of the logical block and verify that the correct types of inputs are provided. Make sure that no inputs are undefined or floating. | ||
| + | * '''Power:''' | ||
| + | **For each internal connection, verify that the voltage levels (range) are consistent. For example, if the signal is +/- 5V, it should not suddenly become+/-10V somewhere in the design. Check for consistency in the "high" and "low" voltages for logic values. | ||
| + | * '''Signals:''' | ||
| + | **For each internal connection, verify that input signals match the output signals of other devices/blocks. Verify that every input signal comes from somewhere, and that every output signal is used by another element. Verify that the types of signals are correct and consistent. Check timing requirements for the signals. | ||
| + | * '''Software functions:''' | ||
| + | ** In order to perform a test before programming, define the equivalence classes, see [https://en.wikipedia.org/wiki/Equivalence_partitioning Wikipedia], for the input and design the black box test according to the classes. | ||
| − | + | '''Outcomes:''' | |
| + | Interface analysis can be done either formally or informally. You always need to have design documentation that describes interfaces, and you have to make sure that these are consistent and updated. | ||
| − | + | Whether the interface analysis is documented in an analysis report (or in your desktop notes) depends on who needs the output. If your component is part of a larger sub-system, it is recommended to do a set of common specification for analysing interfaces. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | interface analysis | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | If your component is part of a larger | + | |
== Why == | == Why == | ||
| Line 71: | Line 76: | ||
''A small analogy:'' | ''A small analogy:'' | ||
| − | ''' | + | '''Let's imagine building a house:''' |
| − | If the technical platform is | + | |
| + | If the technical platform is perceived as the solid foundation onto which you build your system-to-be, the interfaces are the infrastructure, the plumbing, the wiring and ventilation that are to be installed where we need the "components" in the house. I.e. the toilet needs a correctly dimensioned drain and water to be able to flush, the oven needs power, the floor heating need hot water, etc. | ||
'''Why are the correct interfaces important:''' | '''Why are the correct interfaces important:''' | ||
| − | |||
| − | |||
| − | |||
| + | Imagine trying to mount a toilet if the drain pipe is to small. This would correspond to connecting an electronic controller that requires 48V/10A to a small laptop power supply, capable of delivering 20V/3A. '''It won't work!''' | ||
===Links=== | ===Links=== | ||
| − | * | + | |
| + | * [https://en.wikipedia.org/wiki/Equivalence_class Equivalence Classes] | ||
Latest revision as of 08:57, 17 August 2017
What
Block Interface Design is the process of developing one or more suited methods for connecting two or more modules in a system.
Interfaces between two (or more) blocks must be coherent (i.e. both implement the same interface, allowing interconnection).
How
Ingredients
Depending on the nature of the system-to-be, interface design requires several of the following inputs:
- Block and component diagrams
- SW and electronics specification/requirements
- Circuit board and/or sub-system specifications
- System specification
- Interface documentation (formal or informal)
- System and sub-system descriptions
- Operational concepts
- Product information (e.g. for the complex electronic device)
Process
Interface design is basically the process of iterating through all functional blocks in the system-to-be, assessing:
- Desired functionality
- Required information flow
- Suited standards for exchanging information, power, data, etc.
Interface Identification
Thus, by having a common understanding of the desired functionality, one can select suited interfaces that connect the blocks to be designed, being both HW and SW.
Again, if the interface design activities reveal that functionality has not been assigned in an optimal manner, smaller repartitioning (see Design Partitioning) might be necessary. This can allow for another, and perhaps even better, interface selection.
When you feel that the system interfaces have been identified and described, it is time to perform an Interface Analysis.
Interface Analysis
Interface analysis is a technique to verify that the inputs and outputs of the system-to-be are consistent with the defined signals, inputs, outputs and data of the rest of the system. In addition, the technique looks for inputs and outputs that do not connect with other elements of the system (missing items).
This analysis is vital every time you cooperate with other team members, other teams that develop parts of the system, or simply if you choose to interface a component "on the shelf".
When performing an interface analysis for the architecture of your system, you want to focus on the following aspects:
- Physical:
- Check the number of pins on the device and make sure that it matches the number on the circuit board drawing. If pin assignments are defined, verify that they are consistent between the circuit board and the complex electronics specification. Also, check for pins that are undefined or floating.
- Power:
- Make sure that the correct voltages are applied to the power pins. Is the correct type of power (A/C, D/C) provided? Are the ground pins connected? What voltage levels (range) are acceptable for the input or output? What voltage is considered a "high" or a "low" for logic values? Are fan-in and fan-out requirements met?
- Signals:
- Verify that input signals match the output signals of other devices. Verify that every input signal comes from somewhere, and that every output signal is used by some other device. Verify that the types of signals are correct and consistent. Check timing requirements for the signals.
- Communications:
- If the component/block requires communication via a specified interface or data communication protocol, make sure that the communication requirements are fulfilled on both sides of the end comprising the interface. Check any defined messages or data for consistency across the interface.
- System level:
- Take a step back from the details and consider how the complex electronics work within the system. Look at the functions that the device must implement and consider whether the correct inputs are provided to the device. Will the device have enough information to perform its expected functions? Also look at the broader data and communication paths. Are there any bottlenecks that could affect the timing of data coming into the complex electronics or slow down any outputs on the way to other devices? How would failure of one part of the communication path affect the complex electronic device?
- Parameter ranges:
- For SW blocks, be careful to analyse the required parameters to functions and define the valid range(s) for the data transferred to the function through the parameters. As part of the design specification, it is a good idea to have well-defined parameter ranges to program against.
- Function responses:
- Define valid responses from the functions. In order to design other SW blocks, the response from a function call must be well-defined and known.
During design and realisation, the interface analysis should also be performed on the individual blocks in your design. Here, focus can be narrowed down to following:
- Logical:
- Logical blocks take inputs, process them and produce outputs. Check the description of the logical block and verify that the correct types of inputs are provided. Make sure that no inputs are undefined or floating.
- Power:
- For each internal connection, verify that the voltage levels (range) are consistent. For example, if the signal is +/- 5V, it should not suddenly become+/-10V somewhere in the design. Check for consistency in the "high" and "low" voltages for logic values.
- Signals:
- For each internal connection, verify that input signals match the output signals of other devices/blocks. Verify that every input signal comes from somewhere, and that every output signal is used by another element. Verify that the types of signals are correct and consistent. Check timing requirements for the signals.
- Software functions:
- In order to perform a test before programming, define the equivalence classes, see Wikipedia, for the input and design the black box test according to the classes.
Outcomes: Interface analysis can be done either formally or informally. You always need to have design documentation that describes interfaces, and you have to make sure that these are consistent and updated.
Whether the interface analysis is documented in an analysis report (or in your desktop notes) depends on who needs the output. If your component is part of a larger sub-system, it is recommended to do a set of common specification for analysing interfaces.
Why
A small analogy:
Let's imagine building a house:
If the technical platform is perceived as the solid foundation onto which you build your system-to-be, the interfaces are the infrastructure, the plumbing, the wiring and ventilation that are to be installed where we need the "components" in the house. I.e. the toilet needs a correctly dimensioned drain and water to be able to flush, the oven needs power, the floor heating need hot water, etc.
Why are the correct interfaces important:
Imagine trying to mount a toilet if the drain pipe is to small. This would correspond to connecting an electronic controller that requires 48V/10A to a small laptop power supply, capable of delivering 20V/3A. It won't work!
