Need help? Get in touch with our award-winning support team at support@adisw.com
Simple Case suite is made up of numerous applications and frameworks that can simplify system development, specifically, systems that rely on message based communication between their components. But even in this relatively small niche, there are various technologies and development environments. We would like to help you understand exactly which of our products can assist you in your upcoming development needs and have therefore compiled this section to help you do that by suggesting product combinations based on technologies and needs.
The Data Distribution Service for Real-Time Systems (DDS) is a standard that aims to enable scalable, real-time, dependable, high-performance and interoperable data exchanges between publishers and subscribers. SimpleDDS is a solution for easy development of components and applications that use DDS as the base for data interactions which is based on RTI’s Connext DDS. Adi’s solution leverages their implementation to assist you in the efficient use of DDS technology with minimal DDS skills. If you are developing (or are intending to) a system that relies on DDS for communication, these are the products that will most likely answer your needs:
| What You Want to Do | The Solution |
|---|---|
| Eliminate multiple (and possibly conflicting) definitions in long and complicated text/XML files. | Use ICD16 to define and manage topics and their types (i.e. data dictionary). Access and work on the same data by different teams and levels. |
| Define what data items specific components of the system publish or subscribe to. | Use ICD16 to model the information. |
| Connect DDS publisher and subscriber specification to actual implementation. | Use ICD16 to automatically generate code that only needs one function call to create a domain participant with its subscriptions and publications ready to work. |
| Use simple generic participant-level API, free from need to access complex specific DDS participant hierarchy. | Using DDS Framework you do not need to access readers and writers directly. For example, use readAllTopics() of the participant object to get all inbound data for it. |
| Let developers concentrate on the “what” instead of the “how”. | DDS Framework takes care of how information is received or transmitted, you only need to what to do with it. |
| Develop a sophisticated framework for handling DDS. | Build it on top of Adi’s DDS Framework (currently available in C# and C++). |
| Mix DDS with technologies such as TCP, UDP, RS, MuxBus. | Use ICD16 to define participants and data of all interfaces regardless of technology. Determine specific output only at code generation stage. Use appropriate framework (see below) for each technology or develop your own. |
STANAG 4586 is a NATO Standard Interface of the Unmanned Control System (UCS) Unmanned Aerial Vehicle (UAV) interoperability. It includes data link, command and control, and human/computer interfaces. A Vehicle Specific Module (VSM) is the functional unit responsible for enabling control of a legacy UAV, which is not compliant with STANAG 4586, through the standard Data Link Interface (DLI). Over the past 10 years, Adi Mainly Software has specialized in developing VSM units for numerous UAV systems with a myriad of payloads and capabilities. To streamline the development process, we have built a very comprehensive set of tools that drastically reduces the effort needed and shortens time to market for these (and similar) systems. If you need to develop a VSM unit to enable control of a UAV through a STANAG 4586 compliant Ground Station, we have the following products for you:
| What You Want to Do | The Solution |
|---|---|
| Define DLI data and UAV specific data | Use ICD16 to define the messages between the units of the system (CUCS, UAV, GDT, ADT, PYLDs). |
| Specify how DLI commands are translated into specific UAV / PYLD commands and vice versa. | Use Junction to connect elements from incoming messages to outgoing messages via calculation functions. |
| Define message sending triggers, acknowledgment schemes, and delivery guarantee specifications. | Use Junction. |
| Implement data specifications defined in ICD16 and Junction in C++. | Use ICD16 to generate C++ code that includes all message classes and their behavior specifications as well as connecting code for the translation of elements. |
| Implement message behavior in C++. | Junction Framework uses generated code to give you an automatic mechanism that handles message behavior and calculation of elements. Use the framework’s supplied TCP, UDP, RS protocols or roll out your own. |
| Simulate UAV messages, DLI messages, or both for testing your application | Use PeasITE simulator to inject, receive, display, and record messages from VSM application using its built in protocols (TCP, UDP, RS). |
| Automate VSM application testing. | Use PeasITE to create testing scripts for each functionality. Batch them together and run automatically for smoke and regression testing at every release. |
For less specific systems that use message passing as their means of communication, we have the following solutions:
| What You Want to Do | The Solution |
|---|---|
| Define external or internal interface data and units that share it | Use ICD16 to define CSCIs (including sub components) and messages. |
| Define failure conditions in the system calculated from data element values and define how to react to these conditions. | Use FDM16. |
| Create ICD/IDD/IRS documents for system external / internal interfaces. | Use ICD16 to generate reports in IDD format that list all the interfaces of the system. Order a custom made report if specific style needed. |
| Implement communication handling in C#. | Use AMF Framework with ICD tool’s AMF generation. Leverage its supplied communication protocols and message handling features. |
| Define MuxBus interfaces and their properties. | Using ICD16 you can define MuxBus units as well as all the necessary properties for that bus (BC, RT etc.). |
| Implement message structure definition, initialization, and conversion handling in C language. | Use one of ICD16’s various C code generations that come supplied with the tool. Order a custom tailored generation if can’t find a suitable one. |
| Implement message handling in C++ language. | Use Junction Framework with Junction C++ generation or use one of the C code generations. Order a custom C++ generation if not happy with the first two options. |
| Blackbox test your application/hardware which uses TCP, UDP, RS, MuxBus communication. | Use PeasITE simulator with its built in communication protocols to inject, receive and record all outgoing and incoming messages of your tested unit. |
| Blackbox test units that use other communication protocols or have complicated protocol logic (special checksum calculation for instance). | Extend PeasITE using our framework to easily define specific driver functions and policies in C++. You can also manipulate the message data at the application level by writing a simple C# extension on top of the generated ICD16 code. |
| Automate blackbox testing for smoke and regression tests | Use Test Manager (requires PeasITE) to control simulation using test scripts. Batch and run them automatically for every release. Generate relevant part of STD. |
Need help? Get in touch with our award-winning support team at support@adisw.com