Typically, interfacing a large number of devices in a complex infrastructure is a difficult and expensive job. In addition, the manufacturers of electronic devices often send critical components, such as microcontrollers for example, into obsolescence. For a given design, each time a microcontroller is changed, whether one from the same manufacturer is used, perhaps with changed features (I/O, peripherals, RAM, FLASH . . . ), or, above all, when one from another manufacturer is used and therefore with completely different specifications, not only with a hardware redesign of the device becomes necessary, but also a software redesign process, known as porting, is required.
Porting is the process of writing software starting from other, earlier software, so that it can be used on a different hardware platform, to ensure that two apparently different devices (board, microcontroller, layout, components . . . ) appear from the outside as if they were the same.
This complex adaptation process must be performed as quickly as possible because it typically happens in a situation where the device is in full production. In addition, it requires a new and complete sequence of tests to certify the functioning of even the most trivial and recurring functionality.
This approach effectively prevents two or more manufacturing companies from cooperating to develop parts of the design because it would be necessary for them to exchange an excessive amount of information and know-how. On top of this, different companies would also have to align themselves in the checking process for common parts, something that is unacceptable for companies that have their own rigid quality process.
For example, one can assume that two or more companies make different hardware for the same application. In their approach to the solution of the problem, different points of view are used, even profoundly different ones. By way of example, with reference to the diagram in FIG. 1, it is assumed that an analogue signal from 0 to 5 Volt must be generated and driven according to a certain philosophy, which is beyond this explanation, as a function of an input signal arriving from a sensor. It could be assumed that company “A” prefers to generate this signal through the generation of a PWM signal by a microcontroller with low-pass filtering, while company “B” prefers to use an extra, serially-driven chip to generate the same signal. Then, perhaps company “C” prefers to use a different microcontroller that incorporates an internal D/A (digital-analogue) conversion peripheral that is able to generate the signal without additional support hardware. Ignoring the generation method, there is still a need (control chain) that leads to the choice of a particular signal level independently of the way in which it has been generated. The signal generation method disregards the meaning of the signal itself.
In the classical approach, each company will create its own accompanying hardware and software, closely bound to the hardware and microcontroller utilized. The software created will include the part for sensor analysis, “control” and 0-5V output value calculation and the software part for the actuator. If either the sensor part changes, or the “control” philosophy changes, or the hardware part of the actuator changes, all of the software must be rewritten and tested again in its entirety. Moreover, each company must necessarily cope with all parts of the design without being able (or wanting) to cooperate in any way in cases of need or upon request by a customer.
USPTO Backgrounds
USPTO Backgrounds