Scheduler

The scheduler, the central element in an RTOS, determines which application code entities get access to the CPU and in what order. In most commercial RTOSes there are three scheduling models: preemptive, cooperative (also called Round Robin), and time-sliced.

Function Library

The function library of the RTOS serves as the interface between the application code and the kernel. Often known as Application Program Interfaces (APIs), these functions encapsulate the operational requirements of the RTOS into its various services. Application code entities make requests to the kernel through these APIs in order to cause the desired programmatic behavior of the application.

Classes and User-defined Data Objects

RTOSes use data structures generally organised into groups or classes by operation type. The user defines the set of objects in each class that the RTOS will use in controlling the application. The names may be somewhat different, depending on the RTOS, but Table 1 shows the most common classes and how they relate to RTOS functionality:

RTOS Properties and Functions

Primary:

• Manage the microprocessor and other resources to meet the requirements of the application
• Respond to, and synchronize with, events
• Move data efficiently between processes
• Manage the demands of the process with respect to an independent variable such as time
• Perform in a predictable manner with operations that take place within a predictable period of time

Secondary:

• Efficiently manage RAM
• Ensure exclusive access to resources

The post RTOS Explained: Components of a Real-Time Operating System appeared first on Quadros Systems Blog.

He writes, “the question on everyone’s mind is, ‘What does this mean for open-source software development?’ The truth of the matter is, Heartbleed wasn’t the real problem. Rather, it was with how we currently view and deploy open-source and outsourced code.”

Choizit goes on to blame, not the OpenSSL team, but the mindless OEM and ODM development teams who blindly use open source software with the assumption that it must be solid.

At Quadros Systems we have long been skeptical of the lemming-like move to open source without a commensurate look at what is really in the code. The lure of “free” software has blinded many to some of the inherent risks.

1. Does the ready availability of open source software and the ability by malicioius hackers to study it make it more prone to trapdoors and backdoors?

2. Do developers assume that because it is open source, thousands of others must have already checked out the code, so it must be safe?

In this new era of “the Internet of Everything” your embedded device may be more vulnerable than ever.

The post Is Heartbleed the inevitable result of open source software? appeared first on Quadros Systems Blog.

With more and more devices being connected to the Internet I thought I would review five steps we recommend to our OEM/ODM customers to protect their embedded devices from attack:

1. Be aware. This can happen to you. Hacking and intrusion can range from malicious fun by bored teenagers to coordinated attacks for terrorism or even industrial espionage. Don’t think your deployed devices are immune from these threats. Do you have security policies in place? If not, start with an assessment of your vulnerabilities.
2. Take common sense steps. Good security begins with avoiding stupid mistakes and the associated vulnerabilities. A few years back a hacker broke into the SCADA system of the South Houston water department. “I wouldn’t even call this a hack,” he said. “This required almost no skill and could be reproduced by a two-year-old with a basic knowledge of [the automation system they used]…it’s usually a combination of poor configuration of services, bad password choice, and no restrictions on who can access the interfaces.”
3. Investigate how to add security to your existing devices. Are your deployed devices able to be field-upgraded? There are many security measures that can be implemented: IP-layer security, encrypted access to applications, and firewall protection. The Achilles test suite from Wurldtech is a popular way to verify that your systems are safe from a variety of attacks including packet floods, port scanning, and spoofing. Quadros Systems is experienced in working with this test suite and in hardening the network interfaces and application. We have successfully helped our customers pass Achilles level 1 and level 2 tests with our software.
4. Develop your new devices with security in mind. There is no excuse to build a product today that does not have at least basic security protections and the ability to upgrade in the field. Add security specifications to your product development plan. Talk with your customers about their security requirements.
5. Add security management and event reporting to new devices. Many embedded devices today are visible to hackers but not to Enterprise Security Management Systems.  One result of this is that a hacker can probe a device indefinitely without discovery. By adding a firewall and management agent, this situation can be reversed. Embedded devices can now be visible to enterprise management systems but not hackers.

And talk with us at Quadros Systems about how we can help you add security to your embedded device. We offer a range of protections including:

IP-layer security with Internet Key Exchange

Encryption for remote connections to the server

Firewall protection with available agent to connect to security information and event management systems

Certification Consulting. Achilles® Certification from Wurdltech provides an industry-leading benchmark for the development of the secure applications, devices and systems. It is part of the ISASecure EDSA Certification for Communications Robustness. Quadros Systems has successfully worked with our customers to pass Achilles Level 1 and Level 2 tests.

The post Embedded Device Security appeared first on Quadros Systems Blog.

This feature is included in Atollic TrueSTUDIO v4.1 which was just released last week.

(click on images for larger view)

Get more information here

Atollic® TrueSTUDIO® is the leading C/C++ development tool for ARM® developers, reducing time to market and increasing efficiency in your next embedded systems project.

Atollic TrueSTUDIO is based on one of the most widely used compilers in the world, thus providing proven and reliable code generation, compact code and high performance for ARM7™, ARM9™ and ARM Cortex™ projects. Atollic TrueSTUDIO conforms to open standards, such as the ECLIPSE™ IDE framework and the GNU toolchain, significantly reducing training and porting costs across teams and projects.

More information on Atollic TrueSTUDIO can be found here: http://www.atollic.com/index.php/truestudio

The post Atollic and Quadros Systems Partner to Offer RTOS-Aware Debugging appeared first on Quadros Systems Blog.

1. Unrealistic development schedules set by managers who don’t understand development
2. Deficient documentation of the processor
3. Insufficient errata; struggling with a problem for two years, contacted the manufacturer with no result, and 1 year later there is the errata.
4. Finding and resolving timing issues
5. Weak or poor tools: debuggers, emulators
6. Bosses expecting if I kneel or spend time with the device it may relent and start working
7. Learning NEVER to use a device/processor/controller if there aren’t many ‘how to, why, when” questions on Google. The device is too good to be true or else you end being the only using and fighting the problem.
8. Low level debugging and overall performance of the system
9. Hardware/software co-development. Finding root causes when both the code and the hardware are suspect.
10. A paucity of available low-level-embedded example code
11. Hardware debugging, especially during software integration on a new design where all hardware unit tests showed OK but putting it altogether creates a side effect.
12. A badly written device driver delivered with the H/W; caused havoc and a delay of more than 4 months
13. S/W interface which was way too complex to interpret on an embedded system

Of course at Quadros Systems we would argue that starting with the right software platform can make a big difference. RTXC Quadros RTOS-based software is delivered fully integrated with working drivers and interfaces with a binding to your chosen tool environment. Start with the provided sample project and you are good to go. Our Release Notes with tool caveats can reduce the learning curve up front, and save valuable time when development crunch time begins. We know our customers save weeks, if not months, over developing a product using free or poorly tested software.

Find out more about how Quadros Systems can save you time and aggravation.

The post Biggest problems for embedded systems developers? appeared first on Quadros Systems Blog.

Malicious attacks on Supervisory Control and Data Acquisition (SCADA) and other industrial control and smart grid networks are a major concern. Recently the Industrial Control Systems Cyber Security team noted that there are now several new, publicly available exploit tools that specifically target Internet accessible industrial control system and programmable logic controllers (PLCs). Targeted systems include those from Rockwell Automation, GE, and Schneider Electric. And this is just the beginning of an evolving threat with malicious hacking to industrial espionage, and even cyber-terrorism.

According to a new study from VDC Research security is the now the number three concern for M2M OEMs after cost and performance.

There is now an exposed soft underbelly in many deployed M2M systems that is vulnerable to hacking, denial of service (DoS) or other unwanted intrusion. Most of these systems were not designed to withstand the kinds of sophisticated cyber-attacks we are seeing today. According to VDC most engineers did not even considered security in their prior designs.

Even today embedded engineers are looking to add connectivity without factoring in the potential security risks. Many of these systems are home-grown and do not have the benefit of a commercial real-time operating system or proven security software.

Quadros Systems has been actively supplying security for M2M and embedded systems for many years. Our SSL/TLS package provides application level security to HTTP and FTP protocols. And our IPsec/Internet Key Exchange (IKE) package offers encryption security at the IP layer.

(click for larger view)

Last week we announced our most recent solution to address the network security: an embedded firewall. We have partnered with Icon Labs to offer three stage protection to customers using the RTXC Quadnet Ethernet-TCP/IP stack: static filtering, rules-based filtering and threshold filtering.

Floodgate Packet Filter has been used to provide security for industrial control applications, small footprint industrial firewall appliances and MCU based control devices. It  provides Stateful Packet Inspection (SPI) and rules based filtering to protect embedded devices from real-world cyber-attacks.  Rules-based filtering utilizes white-listing and black-listing to define system criteria such as port number, protocol, or source IP address for protection. Floodgate also features Stateful Packet Inspection (SPI) that provides dynamic packet filtering based on the state of the connection to a device.

The combined solution will add a layer of protection against threats such as packet floods, request storms, port scans, malformed IP packets and corrupted Ethernet frames. It is designed to meet ANSI/ISA/IEC/TS 62443 standards for cyber security. The system is designed explicitly for use in embedded devices with limited memory and processor speeds that require secure network implementation certified to standards such as the ISASP 99 which is measured by the Wurldtech Achilles® Test Platform.

Get more details on network security options from Quadros Systems:

Embedded Firewall

Application Security (SSL/TLS)

IP layer Security

Achilles Test Suite Consulting Services

The post Are security issues lurking in your embedded device? appeared first on Quadros Systems Blog.

We agree with his assessment that the smart phone may be one of the many hubs or gateways used to query or analyze Big Data from sensing and other smart devices but it is much more likely that Wi-Fi and Weightless will win out as the networks of choice for IoT over the LTE network (or its successors).

Wireless network operators are clearly positioning themselves as key players in the evolving IoT space as are Internet ISPs and cable providers. And Verizon is well positioned in telematics, as well.

But The IoT future is much larger than connecting consumer appliances and personal information devices. And it is larger than telematics. Karimi says that rolling out IoT is like rolling out the largest control data network in the world: Home Automation, Education, Supply Chain, Auto Safety, Security, Goods Tracking, Farms, Energy Management, Transportation, Health, Lighting–these are only some of the sub-networks that will form the massive IoT.

Chris Rezendez from INEX Advisors writes in the March 12 Issue of the Boston Business Journal, “IoT, M2M connected device solutions are about as broad as you can imagine. All form factor, configuration and functional footprint of unattended, headless, embedded and discrete devices with some combination of sensing, processing and communications.”

Quadros Systems has been active in smart devices and intelligent gateways for many years. Our customers are already building out early IoT networks on factory floors, in smart buildings, in hospitals and clinics. And we have new developments underway for network security and enhanced wireless connectivity.

As Rezendez writes, “The people and organizations that heard the gun go off months, or years ago who are hard at work on the nth generation of their solution, expanding into their phase II markets, and simply going about the business of building out IoT and M2M markets.”

Find out more about how Quadros Systems can help position you for success in this active and growing market space.

The post Are you well-positioned for the Internet of Things? appeared first on Quadros Systems Blog.

We have been asked many times why we provide full source code distribution with our real-time operating system. There are several reasons.

1. Developers new to using an RTOS or those who have not had experience with the RTXC Quadros RTOS can use the source code to get a better understanding of how the “magic” works. 2. Having the source code means you can compile the kernel code any way that you want, with any compiler switches (e.g. models, or options) that you need. The binary version usually comes built for a specific platform. It is either heavily optimized, which makes the kernel code virtually impossible to understand at assembly level, or un-optimized which hurts performance. With source, you can configure the kernel for your specific situation and requirements (e.g. small footprint or high performance)

3. Often during the development cycle, the application under test will crash in the kernel. The problem is not the kernel itself but is caused by a parameter that was passed to the kernel. Having kernel source code available can help you  identify an application problem that manifests itself by corrupting or otherwise crashing the kernel.

4. When that new version of your compiler is released, your RTOS can immediately take advantage of it via recompilation – instead of licensing another binary version.

5. If you need technical support from us, it makes it easier for us to be able to step through the kernel source code over the phone than try to blindly walk through assembly code. Errors in your code can be more quickly identified.

The post RTOS Source code vs. Object Libraries appeared first on Quadros Systems Blog.

1. You’ve heard it before but you do get what you pay for. That doesn’t mean that a free RTOS is worthless. What it does mean is that you are on your own. Maybe you’re the hero type; a talented embedded engineer that can code yourself out of any situation. Maybe you trust the “community” to help you out if you get into trouble. Maybe you are a newbie and a bit naive about the complexity of embedded development.
2. It’s not really free. What I mean is that it may be free to you (to use) but somebody paid for it. Maybe it was a microcontroller supplier trying to lure you in to using their platform. User beware; you could be locking yourself in to an software platform with limited functionality & support and no upgrade path. Or maybe the license locks you in to a particular processor supplier. What if you want to change?
3. What about middleware? So you downloaded a free RTOS but then you realize you need USB or TCP/IP or a file system? What do you do? License a bunch of software pieces from different suppliers and then piece them together?

At Quadros Systems you are purchasing value and expertise, with years of embedded development expertise. A company that will stand by you, to get you through those days when you are stuck on a difficult problem and behind schedule.

Developing reliable embedded systems is not easy. The smallest integration detail or incorrect parameter can take weeks to debug. Getting the right advice at the beginning of your project can be of critical importance. At Quadros Systems we take the time to understand your project and the assumptions and requirements behind it. And then we try to match our software to what you need. If we don’t have it, we won’t try to force-fit a substandard solution to make a sale.

Want to work with an RTOS company that cares about results? Contact us at +1 832-351-2830, use our information request form to tell us about your project, or send an email to info@quadros.com.

Get more information about the Quadros Difference here.

The post Why would anyone pay for an RTOS or other embedded software? appeared first on Quadros Systems Blog.

The RTXC Quadros RTOS provides three different object classes for passing data. Each class has unique properties that support interprocess communication according to the needs of the application. All three allow both synchronous and asynchronous communication between execution entities through the use of kernel services. And all three support a design that allows multiple producers and consumers for maximum application flexibility.

The Queue class allows user-defined, fixed-size data to be passed in First-In-First-Out (FIFO) order between tasks, preserving its chronological nature. Queues are circular. The kernel copies data from a source buffer into the queue (enqueue) and from the queue into a destination buffer (dequeue) in three variants: simple enqueue/dequeue; enqueue/dequeue waiting on full/empty conditions; and enqueue/dequeue with limited duration waiting on full/empty conditions. The RTXC kernel maintains the status and ensures proper operation on EMPTY and FULL conditions.

Under normal conditions the services associated with the Queue class provide the necessary synchronization. However, in the case of certain transitional conditions when special synchronization is required, queue semaphores are also supported. These queue semaphores are used in connection with RTXC services that operate on a set of semaphores associated with multiple queues or other types of events in order to eliminate polling for available data.

Mailboxes, messages and envelopes
are elements of the Mailbox/Message class

The Mailbox/Message class allows variable length data to be passed from a sending task to a receiving task with or without a priority. Mailboxes are globally available to all tasks and are exchange points for messages sent by a sending task to a receiving task. The sender and the receiver must agree on the mailbox they will use for passing Messages between them. Messages are prepared by the sending task and consist of a message envelope and a message body. As a matter of system safety, the Message envelope is allocated by the sender but maintained by the kernel.The kernel has no interest in the message body other than to see to its delivery at the designated mailbox. Only the sender and the receiver tasks know the form and content of the message. Due to the fact that messages sizes can vary, message services do not copy the data into a mailbox. Instead, they manipulate pointers to the message. The result is a clean, efficient means for passing data of any size.

The developer can choose to pass data in a FIFO manner or in one of two priorities, Urgent or Normal. The receiver task gets Urgent priority messages before those of Normal priority.

A task can send Messages synchronously or asynchronously. For synchronous messages the sending task sends the message and waits for the receiver to acknowledge its receipt before proceeding. (NOTE: it is possible to associate an alarm with the receipt of the acknowledgement so that the duration of any waiting condition can be limited.) For asynchronous message transfers, the sending task sends the message but continues without waiting for an acknowledgement. The task can choose to wait at a later time for an acknowledgement.

Normal send/receive operations have the same three variants as Queues: simple send/receive; send/receive waiting for successful completion; and send/receive with limited duration waiting for success. Like Queues, Mailboxes have related semaphores intended for use with transitional events to eliminate the necessity of polling for available data.

The Pipe class, allows data to be passed from a producer task, thread or Interrupt Service Routine (ISR) to a consumer task, thread or ISR. Pipes are data passing mechanisms in the RTXC Quadros RTOS that permit rapid, unidirectional transfers from one or more producers to one or more consumers. The producer or the consumer may be an ISR, a thread or a task. Pipes are ideally suited to communications applications where data is acquired and buffered at a high frequency and then must be processed rapidly while the next block is being acquired.

Functionally, pipes are buffers of data that are filled by the producer and processed by the consumer. The RTXC Quadros pipe services perform the necessary functions of managing the buffers in the pipe while the actual reading and writing of the data in the pipe buffers is the responsibility of the consumer and producer, respectively. In operation, the producer allocates a free buffer from the pipe, fills it with data, puts it back into the pipe. The consumer gets the full buffer, processes the data in it, and then frees the empty buffer back to the pipe where it can be re-used.

Normally, pipe buffers are allocated sequentially and processed in the same order. However, RTXC also permits the producer to put a full buffer at the front of the pipe instead of at the tail, causing the consumer to process it next.

Pipes can also be associated with thread gates (in the RTXC/ss configuration) so that certain pipe operations can result in operations on associated thread gates. Such a capability permits close synchronization between pipe producers and consumers and minimizes the amount of RAM required for pipe buffers.

Summary

The three flexible interprocess communications object classes in the RTXC Quadros RTOS eliminates the necessity of trying to force-fit one method of moving data into all situations a design might require. The developer can choose the one that best fits the application’s needs and have the appropriate kernel services to implement efficient data transfers for optimal time and memory considerations.

The post RTOS Explained: Understanding Interprocess Communications appeared first on Quadros Systems Blog.