Why
use EmINENT Microsystems products and services?
Our objective
is to obsolete the typical multi-million dollar development
program for custom crafted embedded applications.
Complex
projects consist of hundreds or perhaps thousands of custom
crafted files representing many man-years of investment. To
reduce development expense, software component reuse is commonly
desired, but rarely achieved. One reason is the absence of standard
organization conventions, naming conventions, implementation
conventions, or interface conventions geared to facilitate component
reuse or engineering component modularity. Reuse typically requires
a significant research project to discover and understand what
the detailed components are, exactly how they work, how they
are interdependent, and how to use them. Porting typically means
cut-and-paste into a new project, and then changing significant
portions of the code to suite the new task. Modules that do
succeed in being used in more than one project are typically
peppered with "ifdefs". This type of reuse is tedious,
often takes as long as or longer than engineering from a clean
slate, and often results in kludged solutions.
Standardizing
software interfaces or development processes alone is not sufficient
because the interfaces or processes need to support an almost
innumerable set of potential future applications. If not well-designed
at the outset, each application reuse adds more complexity and
detail so that these interfaces evolve into complex "flexible"
components with bloated size and performance. Expense is multiplied
by additional process steps and iterations - change control, bug
tracking, testing, etc. - needed to compensate for a poor ground
floor design. Also,
because product portfolios contain a mix of CPU's, platforms,
operating systems developed using different tools and instruments
- compilers, assemblers, linkers, test equipment, etc., the typical
inclination is to "standardize" by reducing this variety
and enforcing a common or standard platform, methods, or protocols.
However, components have different properties and tradeoffs, and
market forces rarely allow the usage of a "standard component"
that is non-optimal for the intended application. Change is the
norm, so a reuse strategy must not fight it. Instead of enforcing
"component usage standards", it should enforce "component
interface standards" and "component organization standards"
that support rapid identification of available options and the
flexible combination and easy interplay of any of these different
options to provide different tradeoffs to solving a particular
problem.
The products and
services EmINENT Microsystems offers address abstract issues
such as reusability principles for architectural design, application
construction, and component modularization and organization.
They also address concrete issues such as component implementation
interfaces, existing libraries, build tools, integration with
management tools and processes, product application examples.
In order to accomplish
this we adhere to strict principals with all of our development
procedures. Some examples of this are;
- Organize the components
in a hierarchy that matches a conceptual hierarchy already familiar
to engineers
- A standard directory
hierarchy that is organized according to “is a type of”
and “is composed of” relationships.
E.g.
- Layers of abstraction
in a computer system
- Algorithms, data structures, protocols
- Directory branch
naming provides an unambiguous choice to find any particular
type of code module.
What does all of
this help our customers accomplish?
