 |
 |
 |
 |
 |
 |
 |
home | process | consulting services | development services | bio | links | about | |
 |
||
|
PROCESS The process of developing an embedded system requires a number of steps and considerations: Assuming that the marketing requirements are well understood, and that the business plan has been approved, the next focus is development of the technology and product. As the business plan provides a roadmap for the product, a specification provides the details and requirements of the technology. For most commercial endeavors, a well written and complete specification cannot be over emphasized. A complete and well written spec removes assumptions and uncertainties while informing members of the development team not closely associated with the technical details of development. Whereas the business plan details such topics as: The spec uses the business plan and product definition to create a reference that outlines specific product requirements such as: The spec provides a detailed system description that the entire team from design, development, packaging, test, manufacturing, and marketing will reference, now and throughout the product lifecycle. As such, it must be expected that the spec will undergo revisions as the project advances. Another reason to complete a detailed specification is to save development time. In drafting the spec, the architect is presented with design challenges and tradeoffs that are raised and can be solved before the first design step is taken. Solving these challenges before time, energy, and resources are wasted reduces the overall development time while eliminating confusion and frustration within the development team. A good example relates to testing. Testing is often overlooked and needs to be understood and accommodated throughout the development. When the testing is comprehended in the spec, the necessary capabilities and steps are taken along the way throughout development that enables and simplifies product test. If test requirements are ignored until the end of development, the product schedule and quality are often compromised. Once the spec has been fully developed, the business plan should be reviewed and may need to be adjusted. With this preliminary information in place, it should be possible to develop a schedule which identifies the major development tasks and milestones. From this, the critical paths can be identified and optimized, resulting in the fastest time to market. The budget should also be reviewed at this point to insure that the initial assumptions were within reason. Give the requirements in the spec, the next step is to determine the architecture of the final product. Consideration must be given to the complexity, performance and budget for both the development and final product (Cost of Goods sold).
In most cases, the technology and its capabilities are well understood, and the product development is simply the application of known technologies to a problem. In some cases, the technology itself needs to be developed, and as such, presents a number of unknowns. These unknowns translate into schedule, capability and specification uncertainties. In this case, it will be necessary to identify the critical technical challenges, uncertainties and risks, and to develop contingency plans for the various outcomes. In some cases, depending on the products complexity, the design of the end product may be started immediately; however, for many products, especially those with technical uncertainties, intermediate steps such as a proof of concept, or prototype, may be necessary before achieving the final production design.
Co-developing hardware and software offers the benefit of keeping the entire team moving, and reducing the overall development time. Often, particular challenges in one discipline can be more easily solved in the other, allowing the team to keep moving simultaneously. As part of this intermediate platform, hardware such as breadboards (perfboard or "dead bug"), evaluation kits, single board computers, and "quick and dirty" custom PCB with test circuits can be built, depending on the products and teams needs. For any system that involves a microprocessor or microcontroller, the development of firmware is typically the most time consuming process. Firmware development can take place using assembly code, or as is most common, a combination of assembly and C code.
The choice of an operating system, or lack thereof, needs to be made early in the development process. For most applications, the developer prioritizes and executes sections of code as needed by the application without the need for any third party software. If the system is complex, and needs to manage multiple tasks (apparently) simultaneously, a Real Time Operating System (RTOS) will need to be investigated and purchased. The real time aspects of the O/S enable tasks to be scheduled without delays and executed predictably, in contrast to general purpose operating systems. Keep in mind that the most cost effective firmware is that which already exists, and has been debugged. The principles of modular design and reuse are the goals of any developer. Besides the individual engineers personal experiences and toolkit, the processor manufacturers application teams typically create a wide variety of examples that should be leveraged into your product. One advantage of using an off the shelf development platform, not only gives the team a jump start on coding, but also opens a plethora of existing debugged code specific to that platform. As an example, one can look at code developed around the Arduino platform and associated shields. Along the way, debugging and modular testing is performed. These tests can be intermediate steps or directly against the features found in the specification. As tests are completed they can be packaged into a suit of tests, often called the set of regression tests, and included in the products final test flow.
Modular testing is often ad-hoc, but sometimes utilizing standards such as JTAG serial sequencing can be used during development and final test. An alternative to sequencing is to stimulate and observe a subset of the systems nodes, either through a connector or an array of pogo pins. It is during this time that the production test fixture and sequencing can be developed. In some cases, without the resources of dedicated test systems, custom hardware may need to be developed. Using the same platform that was used during the products development can often be an asset, as it contains the same algorithms and hardware and the device under test (DUT). Much of this code can also be reused in the products self test algorithms. The final step in development testing is characterization. Here, the product features are tested against the spec. These measurements can be automatic or manual, but will most likely be needed again if the final production version of the product is not available, or if the design or manufacturing process changes at any point. Application Software Development For any system that is not a stand alone device absent of connectivity, host software will be needed to communicate with the product. This can be in the form of an installable package for Linux and Windows platforms, or an App for mobile devices. The choices of programming languages for this interface is widespread, as is the complexity and appearance.
Microsoft's Visual Studio Visual C# and Visual Basic .NET Express, provides tools to develop quick, easy, and professional looking Windows host applications. If not for the end user, it enables the development team to test, monitor, record, characterize, and collect statistics on the design. Most large companies have their own manufacturing resources, but for many, reliance on a contract manufacturer (CM) to do the production work is a wise and logical choice. The CM is typically responsible for the manufacture of the PCB from start to finish. Although each project and relationship is unique, the CM's services typically include the physical board design, component procurement, populating the PCB, and soldering, resulting in a board that is ready for final assembly.
Selecting a compatible CM is a crucial part of a products and companies success. As an ongoing process, documentation is an important aspect of the project development. Good record keeping and notes are maintained throughout the development process, and summarized at the end. Below is a description of documentation that is typically needed.
|
||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
|
Once the final architecture has been identified, hardware design may start. In many cases it is desirable to also start software and/or firmware design using an off the shelf alternate platform. Most vendors of silicon hardware offer development platforms for that very purpose. Finding one that is similar, or at least uses the same target processor as the final product, is desirable, though not imperative. Due to the portability of source code firmware, usually written in the C programming language, effort spent on this task can be ported to the final target when it becomes available and has been debugged.
When using C, a compatible compiler must be used to convert the C statements to assembly so that the microprocessor can run it. The cost of the C compiler can run from free (usually limited in some way), to several hundred dollars. Some manufacturers of microcontrollers have adapted the GCC (GNU C Compiler or GNU Compiler Collection) which is distributed by the Free Software Foundation (FSF) under the GNU General Public License (GNU GPL), and as such, is free.
The goal of the developers should always be to find and fix bugs in the design and code as early as possible. The later these problems are found in the process, the more of an impact on cost and time will be. Ongoing testing is critical in optimizing the development cycle and producing a bug free product.
In some cases, host software and connectivity is only needed by the development team itself, to verify performance and functionality. In this case, serial communication using a UART is the method of choice as it has a minimal impact, of both hardware and CPU cycles, on the target hardware. The user interface can be as simple as a terminal emulator, such as PuTTY, or as complex as a full color GUI.
Many factors need to be considered while selecting a CM, and they must be weighed carefully. Such aspects as quality standards, throughput time, and final costs are major considerations. In addition, the CM's values should be examined so that they may align with those of the company. Additionally, the CM can be in a position to help your company by referrals of needed professionals and capabilities. |
© 2014 Vulcan Enterprises LLC | |
Phoenix, Arizona, USA | |