Embedded designs can fail at any stage in the process before reaching production. It is possible that the processor may meet the needs defined in the requirements, but will be inadequate once the software overheads are factored in or there is some device requirement imposed on the design. This means that the procurement is not based so much on the range of capabilities offered by a supplier but rather on the ability of the provider to make assessments regarding feasibility and to integrate hardware and software decisions.
The first consideration here is ownership beyond the system boundary. Many embedded projects separate the board design from the firmware development and thus create a margin for differences in assumptions. It would be wise for potential buyers to look at how the provider makes decisions regarding interfaces, changes in requirements, debugging and hardware versus software tradeoffs. This will be important especially when it is no longer feasible to replace the chosen device.
Stay ahead of the industry with exclusive feature stories on the top companies, expert insights and the latest news delivered straight to your inbox. Subscribe today.
Feasibility is equally worthy of evaluation. The service provider that codes without fully comprehending the technology may set the project up for an inappropriate framework from the start. Experimentation at this stage is preferable to an elegantly crafted schedule if there is uncertainty about available headroom on the processors or support for peripherals. Management should search for a process that can test assumptions in advance of significant design work and can suggest alternate approaches if the initial idea is unworkable. In any case, the early experimental phase will uncover limitations when the decisions are still inexpensive to change.
Architecture should also be judged by how well it supports later modification without making the initial system unnecessarily elaborate. Scalability has value when it is designed into both hardware and software from the start, but excess abstraction can burden small embedded projects with complexity they may never use. The stronger approach is proportionate design. Processing capacity, software structure, hardware interfaces and expansion paths should leave room for likely extensions while keeping the present system understandable enough to modify.
“Acorn Logic Technology begins by understanding the underlying technology and can run preliminary experiments before development when feasibility is uncertain.”
The nature of the end use changes the buying decision. Systems built to support research and development place unusual weight on usability during experimentation rather than only on production economics. Researchers may need to alter test conditions and repeat experiments without constant engineering support. Development tools and interfaces should make that work practical instead of forcing users to understand unnecessary implementation details. In that setting, an embedded development partner should be judged on how effectively it turns an incomplete concept into a usable working system through careful consultation and practical specification choices.
Acorn Logic Technology handles embedded projects through single-person responsibility for the full system, keeping hardware and software decisions under one technical owner. It begins by understanding the underlying technology and can run preliminary experiments before development when feasibility is uncertain. This model is suitable where the early options can be taken if the selection of the particular device in itself or the specifications thereof has any limitations. The hardware and software designs of this model take into account future expandability, while its application in a research and development environment focuses on user-friendliness. For customers that place value on technical ownership and early feasibility assessment along with design adaptability, Acorn Logic Technology is a good option to consider.
