Click Here To Join JalewaAds

Source: Agency

Pure hardware development perspective

Saturday | 16.4.22 | Last Updated 2022-04-16T08:41:30Z

Pure hardware development perspective

 The risk of falling into the complex trap of embedded systems development is high when overconfidence in one's own abilities is coupled with the immaturity of corporate executives. Companies with a strong history of successfully developing and delivering hardware-focused products are vulnerable to this trap. They tend to have customized processes and world-class engineering teams capable of developing very complex hardware products of the highest quality. 

From a pure hardware development perspective, the companies are either in the Goldilocks zone or in the extreme mountaineering zone. Such conditions might convince them that they are capable of developing almost anything---even beyond hardware. Especially if these companies have early success in the development of simple embedded systems, their immaturity can be hidden.
Such companies tend to apply similar management processes and methods to embedded systems development as they do to hardware development. 

Companies fall into the complexity trap not only because of the challenges in the embedded systems development process but also because of the contiguous functions and the mindset, culture, and capabilities of the organizational units involved. The pitfalls of complexity in embedded systems development come in all shapes and sizes. 

An established product development organization is structured around hardware components rather than around systems and their interdependencies. This setup limits development efficiency for example, in integration and bug fixing, if the organizational units responsible for technologically closely related subsystems do not collaborate closely. Worse, it can also lead to inferior system design. The mindset that a task force can solve any problem, even in the late stages of development, may have proven successful in the classic development focused on mechanical systems. However, in embedded systems development efforts, the same “more people, more pressure” mindset may prove disastrous. In particular, architectural design choices made early in the development process are irreversible due to the many interdependencies between systems and software and hardware subsystems. 

After a certain point, starting from scratch or living with the consequences of subpar architectural design may prove to be the only option. IT systems engineering and tool chains are designed for hardware-centric development processes. Simply adding a software development tool chain without proper integration is usually not enough as hardware and software are closely intertwined in embedded systems. Hardware-centric tool chains are largely unsuitable for handling the specific demands of embedded systems, such as handling tens of thousands of interdependencies, software versioning, and end-to-end requirements traceability.

Suppliers are selected purely on cost, not on their own maturity in complexity management as measured, for example, by their history of providing high quality complex subsystems on time. There may also be an over-reliance on suppliers, which could lead to or be caused by the company's capabilities in developing, integrating, and testing embedded systems being too limited to properly handle these activities. Product development financial direction can be optimized for hardware development. When the same method is transferred to an embedded system, the impact is often negative. For example, hardware-focused financial arrangements often lack a total cost of ownership perspective.

Instead, short-term cost savings are typically encouraged, even when the solution requires a long-term cost perspective that incorporates the cost impact of continually updating and maintaining a potentially complex system architecture. Another example is direct cost optimization, which is easier to measure but does not capture all development costs and system complexity. This usually results in additional system variants based on cheaper but worse performing components, increasing the complexity of the system. In addition, the potential benefits of providing on-demand functionality, which would require components with better performance, were not sufficiently considered. Sales departments often request a large set of system variants to meet the needs of various customer segments and to stay competitive. However, this is done without regard to the additional effort required for development, integration, or testing of one more variant. 

In the worst case, adding more system variants causes product launches to be delayed by months or even years, lowering customer satisfaction and competitiveness. Complexity appears in various forms that can be analogized as in a mountain climbing trip to better understand how it manifests in practice and the impact it has.

Latest news Update