You have a question that is not in this list, do not hesitate to send it to us. Click here.
What is component-based software?
Component-based software (CBSE) (also known as Component-Based Development (CBD) or Software Componentry) is a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components.
Components are considered to be a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages carrying data.
For further definition & explanation, please refer to: http://en.wikipedia.org/wiki/Software_componentry
What is NSI?
NSI (NexWave Software Infrastructure) is a component technology that can be run on top of any OS (Operating System) and is dedicated to the embedded market. NSI’s main focus is to drastically improve software reuse and exchange for the embedded market to reduce software cost, increase time to market, and improve system integration, deployment and management.
NSI allows building binary components that run natively without a virtual machine. These components are easily reusable across the various product lines of a company, but also exchangeable between companies without needing to deliver the source code and so without breaking the provider’s intellectual property.
NSI’s main goal is to introduce the emergence of a rich eco-system of components provided by various software companies. NSI offers all the tools needed to integrate these components very easily to build a complete system suited for any kind of embedded device (DVD, DTV, cell phones, PDA, etc.).
NSI includes the following:
- Command line tools (NexDev) to build binary components from legacy or new code (C and C++ languages are currently supported). These command line tools can easily be integrated into any IDE (Integrated Development Environment).
- An interactive tool (NexBuilder) to build a complete NSI system by moving components in a simple drag-and-drop operation. This tool automatically manages component dependencies and hides some of the complexity of the OS.
- A runtime for running an NSI system on a specific OS (e.g., Linux, Windows, µITron, or any other OS).
- A set of mandatory components implementing standardized interfaces that provide an RTOS (Real-Time Operating System) abstraction (scheduling, memory management, and component life cycle management).
- A set of optional components implementing standardized interfaces that abstract middleware functionalities (GUI, file system, etc.).
NSI is OS independent and can be adapted to any OS. Even if the various underlying OSs provide different functionalities and may not provide realtime services, NSI provides an RTOS abstraction that is guaranteed to have the same realtime behavior on any OS.
NSI is not intrusive and so does not add any performance overhead when componentizing legacy code. A little footprint overhead is needed to encode the various interfaces that are imported or exported by a component. The NSI runtime itself has a 100 KB code footprint and a RAM footprint starting from 200 KB.
What does NSI do?
NSI builds software components so they can be reused across various OSs and hardware. NSI components can use all the functionalities provided by the underlying OS. In that case, NSI components depend on the OS and can use it without any overhead.
NSI components are OS independent if they use only standardized NSI interfaces. In that case, NSI components only depend on the architecture (type of CPU) and can be run on any other NSI runtime operating on the same CPU, no matter which underlying OS is used.
What can I do with my legacy code?
NSI has been especially designed to ease the build of components from legacy code. Companies do not have to rewrite or port their current software for it to use only NSI standardized interface (even if they are encouraged to do so). It is, for example, very easy to convert software modules into NSI components that can be used outside the scope of their original project and even exchanged between companies.
Because the NSI component model is not object-oriented, components do not have to fit into a complex hierarchy of object classes. Furthermore, the NSI IDL (Interface Definition Language) is very close to the standard C language; any C API (Application Program Interface) can be mapped directly to an NSI interface. Thanks to this characteristic, it is generally not necessary to modify the original legacy code to componentize it.
NSI is particularly well suited to run legacy TRON-OS code seamlessly on any OS powered by the NSI runtime (e.g., Linux). Note that TRON OS-based applications are the Japanese CE standard today. NSI can easily be extended to run other OS-based legacy code (e.g., VxWorks, PSOS, etc.) on other OSs (Linux).
Why is NSI well suited for embedded devices?
NSI has been designed from the ground up to be an embedded solution. It has been proven in a set of commercial projects featuring top class devices like DVD players and recorders, DTV, cell phones and network devices.
NSI introduces no CPU overhead. Interface calls are performed directly from one component to another without any intrusion of the runtime. NSI memory overhead is kept to its minimal. Component format is very compact and all information that is not needed at runtime is removed automatically at build time.
NSI has very good performances regarding boot time and RTOS functionalities. The tool used to build an NSI system (NexBuilder) has the unique feature of being able to manage the position of the various sections, or the components, by a simple drag-and-drop operation to move them into the various memory regions available on the device (FLASH, ROM, RAM, etc.).
How does NSI handle realtime?
Since NSI components can use the underlying OS APIs, they can use all the realtime functionalities provided by the OS.
NSI’s RTOS abstraction provided on all NSI runtime environments is guaranteed to have the same behavior (inside the NSI runtime scope), no matter which underlying OS is used. Since this RTOS abstraction provides most of the services needed by realtime applications (synchronization objects, message passing, batch, round-robin and FIFO scheduling), a component using it will have the same behavior and will then be usable across all NSI runtime environments (and so across all OSs supported by NSI).
NSI’s RTOS abstraction is provided by two different implementations:
- If the underlying OS offers enough realtime facilities, the implementation uses them directly (native scheduling).
- If not, the implementation includes a complete realtime scheduler that uses low-level primitives available on any OS (virtual scheduling).
Why the NSI runtime cannot be compared to a dynamic linker?
Contrary to a dynamic linker, the NSI runtime knows exactly the prototype of all interface functions involved in the system at any time, as well as the ABI (Application Binary Interface) used by all component implementations. Depending on all these, the NSI runtime can dynamically insert stubs between components if they are required. Stubs complexity can range from nothing (direct function calls are used in most cases) to remote calls with parameter marshalling (ABI adaptation).
Thanks to this unique feature, NSI can achieve things that cannot be done with any dynamic linker or even with other component technologies:
- on-the-fly security checking.
- automatic tracking of interface calls.
The NSI runtime always keeps track of component interactions and so is able to manage components’ life cycles. Functionalities like component tracking, automatic loading and unloading, interface discovery and call, can always be performed dynamically at runtime, even in release mode (i.e., once the embedded device is on the market).
Why NSI components cannot be compared to dynamic libraries?
Component implementations never have to worry about how interfaces are made available to them, so these implementations are always independent from their environment (e.g., they never have to worry about component loading and unloading). Since NSI tools can remove some information from components at build time (such as relocation information), components footprint is better than dynamic libraries footprint.
Dynamic libraries do not provide information about required functions (only about provided ones), so one cannot build a complete system from dynamic libraries. Furthermore, dynamic libraries’ interfaces are not type safe and mismatches cannot be avoided. Dynamic libraries cannot be used from FLASH memory or from any predefined position in memory (XIP: eXecute In Place), which is often mandatory for an embedded device to save memory footprint.
NSI components can be fully OS independent. They only depend on the architecture (i.e., CPU type) for which they are compiled. This means that you can take any ARM compiled component that does not make native OS calls or direct hardware access and use it on any NSI runtime for the same ARM CPU, no matter which OS is used (Linux, µITron, Windows, etc.).
What type of functionalities can NSI bring to my software?
NSI can bring to the embedded market all the functionalities that other component technologies (like DCOM) have brought to the desktop, without the associated footprint and performance overhead.
These functionalities include the following:
- dynamic software update and improvement
- ease of system integration, configuration and deployment
- robustness
- reusability
NSI allows specializing on specific value-added area (niche or expertise), while easily integrating into the whole software system (yours and third-party partners). This gives a combination of the “best of breed” software.
NSI allows the easy assembly of several basic heterogeneous products into one “high level” homogeneous product. For example, a CE manufacturer can take three different products (e.g., DVD, DTV, game station), on three different CPUs (e.g., SH, ST, ARM) and easily integrate these into one single product that operates transparently and seamlessly for the consumer.
