|
Every serious company developing machines,
or any other technical product used by humans should include usability considerations in their design process.
Unfortunately,
even the biggest and most renowned companies sometimes sell products with quite a poor and confusing user interface.
This happen because normally control firmware and user interface are in the same project, and software. In this mode, the
developer is normally focused on control problem, and the user interface will be a second step, somtimes very poor step.
MI Builder solve this problem, it permit to manage the control software and user interface as different job.
|
| |
|
| |
|
| |
| With MI Builder your firmware will be faster and precise, like always, and easy and intuitive to use. |
| |
|
|
MI Builder - Code Generator |
Diagram depicts the development procedure and final product architecture when
using a MI Builder code generator solution.
The code generator tool generates
the GUI source code (GUI Source) and Resource files.
The GUI source code is compiled into the application code and then linked with the
Resource files.
The resulting end product architecture possesses two crucial characteristics:
- The GUI and APPLICATION sources are combined together.
- The graphics libraries and resource files are also linked in a single end binary.
These architectures have high level code optimization and small footprint, but force the OEM
to have different control firmware version for different customers and model.
These characteristics have profound impacts on an OEMs business model when an OEM
is required to brand or customize its product for its end customers.
In the automotive/car infotainment market, Tier 1 automotive OEMs sell to multiple
end customers (e.g.,Toyota, BMW, Daimler Chrysler, Honda, Ford, etc.).
It is a given that each end customer would wish to establish its own brand
(user interface), which may even vary depending on the trim level (e.g., CE, SE, LX, etc.)
|
MI Builder - COTS GUI |
Diagram depicts the development procedure and final product architecture when using a COTS Binary GUI.
The binary graphics engine provides, in native binary format, all the
capabilities needed in a deployed end solution. The OEM needs only to configure the
properties of the objects using the supplied development tool. The binary graphics engine
will display the GUI objects based on the configurations defined in the resource
configuration files.
The resource files are not compiled into the application or
binary graphics engine. Rather, they are separate files stored separately on the target. In
addition, no graphics libraries are supplied or compiled into the OEMs application code.
Rather, the OEM leverages the Events communications API (Interf. Events) to provide
communications between its application and the binary graphics engine/GUI.
The resulting end product architecture possesses two crucial characteristics:
- The OEMs GUI is not bound into the OEM application code.
- The resource files are not bound into the OEMs application code or GUI COTS vendors binary engine.
With these architectures the OEMs can easily customize/brand the user interface for end
customers without affecting any changes in its application code. Since changing
the user interface affects only the resource files, no coding, recompiling or
relinking is required. Rather, the OEM reconfigures its resource files and
downloads them to a separate location in a flash. The embedded engine will
display the user interface based on the new resource file provided.
These architectures have low level code optimization and a medium footprint.
|
MI Builder - Designer |
Con la soluzione Designer, gli OEM che hanno da tempo consolidato soluzioni proprietarie fatte in casa,
potranno integrare la loro offerta con uno strumento di sviluppo ridistribuibile, o completare la loro struttura
di sviluppo interno, mediante un avanzato software di design, che opportunamente configurato, o modificato,
genererà file di configurazione, o codice basato sulle richieste e/o librerie del cliente.
|
| |
|
|
|
Products
