Difference between revisions of "Main Page"
(→Latest News) |
(→Latest News) |
||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
==Latest News== | ==Latest News== | ||
− | {|style="background-color:#CCFF99;" width="100%" cellpadding="2" border=" | + | {|style="background-color:#CCFF99;" width="100%" cellpadding="2" border="0" |
| See us at [http://www.rtecc.com/ RTECC Jan 17, 2012 - Santa Clara, California] | | See us at [http://www.rtecc.com/ RTECC Jan 17, 2012 - Santa Clara, California] | ||
|- | |- |
Revision as of 14:09, 13 January 2012
Latest News
See us at RTECC Jan 17, 2012 - Santa Clara, California |
SimWB 4.1 released on 14 Dec 2011 |
SimWB 4.0 released on 27 Nov 2011 |
About SimWB
How SimWB Works
Product Highlights
Real-Time Development and Execution Environment
|
Platform independent client GUI's
|
I/O support
|
System Architecture
Image: System Architecture
For an in-depth insight into the SimWB architecture, please see SIMulation Workbench Architecture.
Competitive Advantages
SimWB based simulators are pushing the boundaries of rapid prototyping and real-time hardware-in-loop simulators with support for 32 and 64 MATLAB/Simulink on 32 and 64 bit RedHawk real-time Linux operating systems.
1. Throughput and overall system performance
Concurrent iHawk multiprocessing systems running SimWB are based on COTS components offering the latest, leading-edge processor, chipset, memory and I/O bus technology. Solutions that use proprietary hardware are slow in comparison to Concurrent’s latest available COTS-based systems.
With SimWB, individual I/O processes can be targeted to different system cores and I/O buses for parallel execution, thus allowing the simulation loop to run at faster frame rates. Without the ability to run I/O on different cores, I/O processing becomes serialized thus extending execution time of the simulation loop.
SimWB recognizes and utilizes multiple cores by default and there is no limit on the number of cores than can be used by SimWB.
2. I/O handling
In SimWB, all I/O is performed by processes outside of the Simulink models, thus allowing the models to be independent of the intricacies and specific behavior of the I/O devices. This provides flexibility and makes it easy to remap I/O when necessary. In other HIL solutions, I/O is implemented via Simulink S-functions that are embedded within the Simulink model. They are, for all intents and purposes, part of the model.
3. I/O limits
There are no practical limits on SimWB configurations. Concurrent iHawk systems can be configured with thousands of hardware I/O points.
4. Parallel processing
SimWB provides multi-model support where individual models can be targeted to separate CPU cores for parallel and faster execution.
5. Ease of system upgrade as requirements change
SimWB operates with minimal Simulink-specific dependencies. This allows it to support new MATLAB/Simulink releases with little effort. Because the bridge to Simulink is via the Real Time Database, there are only a handful of S-functions to port and/or test against new MATLAB/Simulink releases. Other HIL solutions must port and/or test all of their I/O S-functions for all their supported devices before they support a new MATLAB/Simulink release.
6. Platform independence
Concurrent’s iHawk platforms running RedHawk Linux and SimWB are open architecture systems. Simulink models that run on Concurrent systems can also be made to run on other systems with minimal effort. Concurrent’s SimWB solutions also support both Linux and Windows client platforms. The use of HIL blocks in the creation of the model environment allows I/O to be run independently of specific hardware platforms.