Engineers must often develop work products under schedule pressure. When engineers are developing an Item definition, we tend to write down a description of the system the client has in mind, and how they would implement the system with a particular structure. As engineers, we may say to ourselves, “this is obviously the only way to do it”.
However, such thinking doesn’t allow for technological progress. For example, a given system may need vehicle speed in order to perform some safety function. In the early 90’s, before ABS was a standard feature, vehicle speed was generally provided from a sensor on the output shaft of the transmission. But in the future, it may come from some other source… a GPS based system for example. One needs to think about what information is needed, and not specifically from where it comes.
The controller is similar. It is often assumed in the concept phase that a given controller will be implemented in a standalone module. As more capable electronic modules are developed, there will be greater emphasis on integration of features into ever more capable modules. Therefore, calling out a particular module in the initial phase of development would require modifying the item definition when going from the concept phase to a product development phase.
And finally, when we turn our attention to actuation, again we often have a pre-conceived technical concept in our minds. As before, we should be careful about over-specifying technical implementations in the Item Definition. For example, a specific actuator may work for the current system but may not have the correct technology in the long term. Consider an electric steering column lock, describing an actuator that locks the steering column may work for today’s vehicles but that solution would not carry over to an autonomous vehicle with no steering column. Clearly, the functionality of locking the steering does not depend on the presence of a steering column.
Engineers like to solve problems. However, we must challenge ourselves to think of concepts in a more general framework in concept-stage documents such as the Item Definition. We can avoid constantly updating documents as the technical concept evolves, by defining those documents independently from the implementation.