KIM ROWE

image

Biography has not been added

RoweBots1

's contributions
Articles
Comments
Discussions
    • "RIP Bernie, you will be missed by many of us at RoweBots. "

    • "Please see my comments in part 1 - basically this is a proprietary RTOS with a system generator. "

    • "The entire premise for this tool is incorrect. It is yet another proprietary RTOS claiming to automate system generation. \n\n\"Disadvantages include the fact that the system is difficult to debug because much is hidden from the user. It is also requires a large memory since it needs to support all possible users with various kinds of applications, and so it incorporates features that each particular system may not be using\" \n\nThis may be true for some RTOS solutions but not for most of the main competitors. Sophisticated tools are provided to diagnose errors and examine timing and scheduling issues and OS status.\n\n\"Although the RTOS is optimized for the particular processor to which it is ported, that is often not the processor that is ideal for the application and is probably not the most low-power processor for the application. This is because RTOS vendors have an interest in porting their RTOS only to high-end processors so that they can charge more for these tools. \"\n\nThis is also incorrect. Many RTOS solutions port to a broad range of processors focusing on low power (Unison WearableOS for example) and many companies focus on delivering the solutions that customers want.\n\n\"\u00a0In particular, off-the-shelf RTOSes need a memory manager to keep tasks from interfering with each other.\u00a0 \"\n\nAgain this is simply not true.\n\nIt seems to me that you need to see this as what it is. It is a proprietary RTOS with a system generation tool. Whatever happened to open system concepts?\n\n"

    • "Its amazing to me as well to watch all these product development efforts for all manner of devices and see security as absent or a last thought add on at best. Its really time for change."

    • "Colin, I agree with all your comments above but feel that the issue of standards is the most important issue but neglected in your analysis. By standardizing on POSIX for example, there is a wealth of software that may be reused in the environment and this is the most effective way to develop an application. Nucleus does support POSIX as does the Unison OS that we produce. The benefits of porting to and from the Linux space are pretty clear. In Unison I know that there is no penalty for adopting the dominate OS standard (POSIX) - could you comment more on this?"

    • Well said Bernard. As one of the POSIX or Linux compatible small resource versions on your list (full disclosure), I know that the migration of applications from Linux to Unison OS is generally very simple and gives developers a chance to a reduced footprint, zero boot time version with no cost or risk other than the porting time. Unison has both the IoT protocols and the security solutions today to deliver quickly and easily. www.rowebots.com

    • The Harmony offering is interesting in that Microchip decided to provide a proprietary offering rather than stick to proven standards like POSIX which would have allowed migration to/from embedded RTOS and Linux solutions on any architecture. Of course, focusing on components which run only on PIC32 family products eliminates portability to other families of processors if you run into limitations (and all processors have their limitations). Although it attempts to address the plethora of "free" Microchip modules that don't work together, it still tries to keep users locked in. Generally, maximum flexibility is essential in today's rapidly changing environment. Disclosure: We offer components for PIC32, ARM, Rx, FPGAs and other processors.

    • This is a great comment Rich because as engineers we ultimately trade off cost, features and performance. An experimental approach is required in this case. In terms of performance, for all these small connected devices, really all you can do is test the performance using tools like iPerf to see if it meets your needs. Compute time performance is generally not the issue - but run time or power consumption is often a key issue. If the power is a concern due to added security, but the computation resource is more than adequate, a reduction in the clock rate might get you back to the place you need to be. In terms of flash and RAM resources, it depends on the system that you have under consideration. In the case of the Unison RTOS, we offer a memory space calculator which estimates the worst csae memory usage in both flash and RAM. In terms of the overhead in bits to encrypt messages, it really depends on the users choice of encryption algorithm. They are typically block ciphers which will add bits to fill a block which means overhead (AES, DES, 3DES). This means the transmission time increases.

    • The compute time goes up as the length of the key increases. There is hardware accelerators included in many chips today to reduce this costs. Typical costs for AES are: +20% for 128 bit to 192bit and +40% for 128 bit to 256 bit keys. Of course, some security features are not nearly as important too. SSH and SFTP are typically used occasionally. while TLS and IPSec are used for each message and are of real concern. It is best to focus your analysis on the message transmission overheads as these will be most commonly incurred. For wireless protocols, all messages are secured across the link if the link is properly set up. In this case, end to end security using TLS or IPSec is a good addition but for wireless routers you may get away with securing the router to cloud link and leaving the wireless security to and from the sensors secured with the wireless security, reducing computation on the sensor nodes. It is really application dependent.

    • It is true that on all systems, filtering should be enabled to exclude incoming messages on any unused ports (think firewall features). One solution to the lack of filtering or firewall capabilities in the embedded stack is the elimination of any incoming messages and polling of the server, so this approach will work. A superior solution is the use of a fully functional tcp stack with filtering or an integrated firewall. This eliminates the need for polling. If the deployment is ten devices, eliminating polling may not matter but if the deployment is ten million devices, or the link is over satellite with quite a few devices, polling is not the best solution. Unison OS offers filtering capabilities which eliminates this restriction. Many other MCU or small MPU TCP stacks do not offer this. Other thoughts and comments Rich? Anyone else?