Embedded System Design and Development is the overall implementation of RoweBots one stop shop for Internet of Things OEM designs. Satisfied customers are our primary concern and embedded systems design and development projects are the best means to realize this success. This approach takes your vision and transforms it to reality working within the limitations of your company and existing team. Projects start with requirements specification refinement using our embedded system design and development skills to augment your team. By starting at the systems level you can be assured that the final products will work well in it's intended environment and will meet or exceed your clients expectations while minimizing time to market, risk and total cost of ownership..
Embedded System Design Principles
- ● System specifications which consider all aspects of the system are the best means to make sure that all top level concerns are addressed during development.
- ● The various hardware and operating system platforms for the system must be clearly identified with the corresponding connectivity options so that the development of the run time environments can happen in parallel and in a timely fashion for the application development.
- ● By choosing the system architecture there is inherent decisions made about the location of modules and data.
- ● From the information about the location and type of data, and the need to exchange information in a machine to machine communication sense, a picture of the amount of information at different locations and the data transfer rates can be established. This is critical to know to ensure that communication links do not become bottlenecks.
- ● From the specification of each node in the system, a set of requirements can be created for the system level architecture. From this specification various methods can be applied to each node to realize an operational node, and then an operational system. Note that these implementations must be synchronized to support testing and incrimental development.
- ● During the embedded system design phase simulations and prototypes may be used to ensure that the expected results are achieved.
- ● Standards should be used throughout - POSIX RTOS components and POSIX based server components or interface device components should be used throughout unless historical versions force other choices.
- ● Off the shelf modules should be used where possible.
- ● Total cost of ownership should be monitored during the systems design and a plan for the long term should be respected.
- ● Time to market should be minimized if at all possible to avoid market share losses.
- ● If security is required (and it is in almost all systems today) this should be included from the outset, including the cost of setup and admistration. It should not be an after thought. It should include all aspects of security.
- ● Mainstream microcontrollers (MCU), microprocessors (MPU), digital signal processors (DSP), digital signal controllers (DSC) and FPGAs are typically considered for the designs of the deeply embedded portions of the system.
- ● Vendors and architectures of choice for embedded hardware include: Arm Cortex M0, M3, M4, A8, A9, R8, Texas Instruments Stellaris, Tiva and Sitara with beagleboard and beaglebone, STSTM32 using Arm Cortex M0, M3, M4, Renesas using RX and SH2A, Microchip using dsPIC, Pic24 and Pic32, NXP using Arm Cortex M3, M4 for 1700 and 1800 microcontrollers, Fujitsu Arm Cortex M3 9Mxxx microcontrollers, Microsemi SmartFusion 1 and SmartFusion 2 FPGAs with Arm Cortex M3, Xilinx Microblaze, TI OMAP and TI DaVinci.
- ● Servers of various descriptions are considered for the backend server, database and archive machines.
- ● Phones, tablets and PCs of all descriptions should generally be supported in a transparent way.
By using these principles and making sure there is a clear written understanding of what is to be done solves many development problems. Our joint team can work more on a prototyping basis; however, this is best done for smaller projects to prove specific features. Once the features and capabilities are clarified, a clear written specification will eliminate significant rework and ensure delayed implementation of features are considered during implementation.
Embedded Systems Design and Development Modeling
There is a broad set of models used to refine systems level design and ensure development proceeds efficiently. These modeling techniques are used throughout the process for a variety of risk reduction strategies. Typical techniques include:
- ● Object oriented design and actor models or homomorphic programming complete with scenarios and design templates
- ● Cocomo
- ● Function points
- ● Historical analysis or Analogy
- ● Expert estimates
- ● SLIM
- ● State machines
- ● Petri nets and colored petri nets
- ● Cut Set Function Allocation
- ● Simulation
- ● Throughput models
- ● Graph theory
- ● Complexity theory
- ● Catastrophe models
- ● Fuzzy logic
- ● Neural networks
- ● Markov and Bayesian Models
- ● System and software architecture specifications
- ● Simulation
Using a combination of these models, the system can be reduced to a set of components, system performance and resource usage can be predicted and the interaction of the elements can be understood. From this detailed understanding risk can be reduced and the probability of problems during implementation can be reduced.
Embedded System Requirements
- ● The embedded system requirements specification should include a complete specification of the various core internal and external variables of the system on a node by node basis.
- ● The variables will determine the size of the system and given that the algorithms are known, should largely reflect the cost of development.
- ● The embedded system requirements should include all the files that are required on each node. Each additional file will also increase the cost of the system.
- ● All underlying operating system modules and run time support features should be identified. The embedded system requirements should include a list of these modules, from wireless connectivity for machine to machine communications through wireline communication, file systems, database requirements and GUI support.
- ● The relationships and transformations of variables should be stated if known. A precise statement of the transformation will make the implementation of the system much simpler and eliminate rework later during system integration. Of course this is still at a high level, and will not include all variables but should include the key variables which are transformed.
- ● If any control loops are necessary, evaluation of the potential performance of these loops should be investigated at this point. Under performing loops will lead to a need for fewer loops, simpler algorithms or improved hardware.
- ● Embedded system requirements at this level should clearly state the underlying hardware, the software required to support it and the performance and resource usage of each component. Using this information, the operating system size on the given hardware can be specified and a clear evaluation of the room available for the application can be made.
- ● Prototypes are a good idea at this point and hardware options along with the underlying software modules should be completely evaluated to ensure that they meet the embedded system design requirements.
- ● Simulations which eliminate any risk are an excellent idea at this stage. In particular, when the final system cannot be easily modelled this is an very good choice.
- ● Diagrams should be used throughout along with mock up interfaces which outline the various screens and user interaction sequences or user interaction scenarios.
- ● Using a variety of methods, from these specifications, estimates can then be made for the costs on a node by node basis.
- ● For each node, off the shelf software is selected where possible. Although this is a design decision, if there is specific assumptions about the design approach and features required, if this is used to focus thinking it provides a faster convergence on the final system design.
- ● For the embedded components, typical items are: Internet protocols or embedded networking, embedded file systems, serial I/O, wireless modules for bluetooth classic and smart/smartready, zigbee, WiFi, 802.15.4, UHF, GPRS/GSM and LTE. With the assumption of an M2M or Internet of Things design, many of these modules are required.
- ● A focus on modules for wireless implementation is assumed for less than 20K units of the design.
- ● The IDE and other tools drastically affect the design too. Some tools are only available with certain architectures and these tools may be essential for the design. By including advanced debugging and simulation ideas at the requirements level the correct overall solution is more easily achieved.
- ● Typical IDE offerings are from: Mentor, IAR, and the various vendors including Texas Instruments, ST Microelectronics, Microchip and Renesas.
- ● Typical advanced tools include: UNISON RTOS Object Viewer, Remedy RED - Remote Event and Data analysis tool, iperf, UNISON size calculator, and the Remedy bootloader which is used for remote field service. By working this in at the requirements level, significant time and effort can be saved.
Embedded System Software and Hardware Design
From the information specified for each node, the requirements can then be mapped into Embedded Software Design and Development, and Embedded Hardware Design and Development. These two topics are discussed in associated pages.
- ● Project management preceeds all of the above work. It should be first, with the second major step being Embedded System Design which is an anlysis and design of the entire system.
- ● The Embedded System Design principles are applied first resulting in an embedded system requirements document. This document includes any prototyping and simulation at the system level.
- ● The embedded systems requirements for each node are then based on the higher level embedded system requirements document.
- ● Specific requirements are firmed up before a specific fixed price contract can be entered into and should also be completed before any time and materials agile development is done. The requirements can be written on a time and materials consulting basis or by the customer that requires the system. The most important aspect is that they are as complete as possible and that risk has been removed as much as possible before .
- ● A project charter and a project plan are written and signed off. They will detail all aspects of the project in a manner consistent with PMI standards.
- ● Project start dates are always fluid due to fluctuations in sign off times by the client and resource allocation on a first come first served basis.
- ● Our values during these projects are clearly stated under the company section. In short we want our customers to be delighted not satisfied and we will put our customers ahead of short term profits.
- ● A project manager will monitor each project. The structure and updates for the projects will be determined in the project plan.
- ● Each project will have all results stored on line each day and all results will be visible to any project participant at any time.
- ● The project plan will also transform the embedded system design into an implemenation if that is within scope. It will complete development of embedded system hardware and software designs for each node and specify and implement the assembly and system level testing of the entire embedded system design and development process.
- ● All project plans should work towards the goals of minimizing time to market and minimizing total cost of ownership. This means maximizing standards like POSIX and reusing software where ever possible.
- ● All projects will have postmortem analysis.
- ● All projects are unique and are individually quoted. Please contact us for a quote.
Embedded system design and development is demanding; consult us to make sure that the total cost of ownership and the time to market for your project has been minimized..
You don`t have permission to comment here!