Application of processor modules in instrument making
My last post about entering the market of the most powerful processor module on the OMAP4460 did not cause any incredible discussions, although there was an interest in the topic. From the experience of industry communication with people "in the subject line" (here I mean hardware developers of various ranks, from engineers directly to technical directors and owners of such companies), I can conclude that at least almost everything is aware of the existence of processor modules Many people simply do not know why they are needed - what the salt is and where the dog rummaged.
The use of processor modules in the development of devices radically changes the process itself, and not only its technical component, but also its economic and marketing one.
One of the most important advantages is the time from the start of development to the launch of the product on the market. It is reduced by orders of magnitude.
')
For example, let's consider the classical development method (some call it a method of using “discrete” elements) and a modern one, using processor modules. In the first, classic case, we take the processor and the components “loose” and start building the future device from scratch. At the same time, we independently solve difficult engineering issues of wiring complex elements, such as, for example, RAM. In the second case, we take the finished processor module and build the device around it. The most important components are already mounted on the module and the carrier board is already relatively simple in terms of design.
Consider two real comparable projects from the practice of the r & d division of my company:
The first is a universal industrial controller, application areas: industrial automation and utilities (engineering systems management).
The second device is used in advertising - the rotation of commercials on video monitors in business centers, a representative of Digital Signage class solutions.
The prefix "industrial" in each of the products indicates that industrial requirements for reliability are applied to them. That is, if you hang media player at home - it is unpleasant of course, but the trouble is small, not to overload for long. In the case of our products, downtime is unacceptable, and overloading the media player, which is installed thousands of kilometers away from you, can be a daunting task, and if there are hundreds of them in the network, then the task is raised to a cube. Uptime devices from both projects are measured over the years.
The first one was developed according to the classical discrete scheme: they set the task with a detailed description of the functional, decided on the processor, picked up the bundle, parted it, got a prototype, which they started to debug, ported linux. In the end, after a few iterations and various tests received the finished product. Those. from and to - this is entirely the development of a single team of engineers, circuit engineers and programmers.
The second was based on the experience gained, but already on the basis of the processor module: here, too, based on the task, we determined the functionality and performance requirements, chose the processor module. Next, we put a simple board on which the integrated amplifier, 3g-modem and connectors were placed - the device is ready! All stages with porting the OS, writing and debugging the drivers, outputting the “iron” part to the combat characteristics have already been largely solved by the bearded guys of the manufacturer of the processor module and the image of the loaded OS comes complete with the processor module in finished form.
So, omitting the development of application software (since it can take completely different times, and in this case, the development of iron does not apply) we get about this set of steps:
Now the prose of life: in the first case, development took 14 months from launch to the advent of the combat version of the device. In the second - three months! And I'm not joking here!
Drama appears when you begin to translate these figures into money and prospects: now, when everything is progressing so rapidly, a delay of a year and a half can kill your project - it can become outdated, even before it is born.
Here is a more understandable investment schedule for bringing a device to market:
The use of the classical discrete development method in the second case would delay the appearance of the first series of equipment at 11 months. For a customer who ran his business on this, it would mean 11 months of lost revenue!
And now imagine that there are two different companies that bring competing devices to the market, developed on these two approaches ... Who is the winner? The answer is obvious.
The use of processor modules in the development of devices radically changes the process itself, and not only its technical component, but also its economic and marketing one.
One of the most important advantages is the time from the start of development to the launch of the product on the market. It is reduced by orders of magnitude.
')
For example, let's consider the classical development method (some call it a method of using “discrete” elements) and a modern one, using processor modules. In the first, classic case, we take the processor and the components “loose” and start building the future device from scratch. At the same time, we independently solve difficult engineering issues of wiring complex elements, such as, for example, RAM. In the second case, we take the finished processor module and build the device around it. The most important components are already mounted on the module and the carrier board is already relatively simple in terms of design.
Consider two real comparable projects from the practice of the r & d division of my company:
- Development of industrial controller smartCS
- Development of an industrial greenGo media player
The first is a universal industrial controller, application areas: industrial automation and utilities (engineering systems management).
The second device is used in advertising - the rotation of commercials on video monitors in business centers, a representative of Digital Signage class solutions.
The prefix "industrial" in each of the products indicates that industrial requirements for reliability are applied to them. That is, if you hang media player at home - it is unpleasant of course, but the trouble is small, not to overload for long. In the case of our products, downtime is unacceptable, and overloading the media player, which is installed thousands of kilometers away from you, can be a daunting task, and if there are hundreds of them in the network, then the task is raised to a cube. Uptime devices from both projects are measured over the years.
The first one was developed according to the classical discrete scheme: they set the task with a detailed description of the functional, decided on the processor, picked up the bundle, parted it, got a prototype, which they started to debug, ported linux. In the end, after a few iterations and various tests received the finished product. Those. from and to - this is entirely the development of a single team of engineers, circuit engineers and programmers.
The second was based on the experience gained, but already on the basis of the processor module: here, too, based on the task, we determined the functionality and performance requirements, chose the processor module. Next, we put a simple board on which the integrated amplifier, 3g-modem and connectors were placed - the device is ready! All stages with porting the OS, writing and debugging the drivers, outputting the “iron” part to the combat characteristics have already been largely solved by the bearded guys of the manufacturer of the processor module and the image of the loaded OS comes complete with the processor module in finished form.
So, omitting the development of application software (since it can take completely different times, and in this case, the development of iron does not apply) we get about this set of steps:
Now the prose of life: in the first case, development took 14 months from launch to the advent of the combat version of the device. In the second - three months! And I'm not joking here!
Drama appears when you begin to translate these figures into money and prospects: now, when everything is progressing so rapidly, a delay of a year and a half can kill your project - it can become outdated, even before it is born.
Here is a more understandable investment schedule for bringing a device to market:
The use of the classical discrete development method in the second case would delay the appearance of the first series of equipment at 11 months. For a customer who ran his business on this, it would mean 11 months of lost revenue!
And now imagine that there are two different companies that bring competing devices to the market, developed on these two approaches ... Who is the winner? The answer is obvious.
Source: https://habr.com/ru/post/142317/
All Articles