Best practice for larger DDS project

Hi Tao,

There are many large projects (large systems with hundreds of nodes and/or 100's of developers) using DDS.  Anything from the NASA space launch system to the control of hydroelectric power-generation plants to patient-monitoring systems in hospitals.

However, what you're asking for isn't easily addressed in a forum setting.  From your profile, it seems that you work for Siemens?  RTI already works with Siemens on many different projects.  If you could send me your email address privately to howard@rti.com, and let me know where you are located. I can ask an RTI account team to get in touch with you.  Many of the subjects that you're asking about is better answered in context.

In the meantime, I can point out some features/tools/processes below:

1. How to manage IDLs, will there be a single public IDL for all nodes, then some private / protected IDLs for some cliques of nodes according to the needs. I feel IDLs shall be treated the same way as header files, is this generally correct?

         Yes, IDL are used to define the Data interfaces in a system.  There can be interfaces that are general to an entire system, specific for a subsystem, as well as private, not to be used outside of a subsystem or module.  Just like header files, you don't expect use or define a single header file for coding, neither do you with IDL files.  IDL files can refer to other IDL files (for base or common definitions) and should be "owned" by the appropriate development team.  Some IDLs may be designed at a system architect level, others at a submodule level.

         So, yes, a system typically use multiple IDL files, which are configuration managed, etc....much of the philosophy/programming guidance/coding practice of deciding what header file to have, and to have separate or a single header file, applies directly to the decision with respect to IDL files.

      2. How to manage QoS for hundreds of nodes across platforms. Is there a central engineering tool for both QoS and IDL configuration, or we need to do it from text editor?

        You can use whatever tools that you have, from a text editor to a database to a DDS-centric tool such as RTI's System Designer.  There are also UML tools like IBM Rhapsody, CATiA Magic Draw that have plugins that allow you to design IDLs and QoS.  The Mathworks Simulink and National Instruments LabView also have integrations with Connext DDS.

        However, in practice, we have seen some customers who have developed their own development architectures and use tools like Doors or custom requirements capture tools based on databases or even spreadsheets, and then from the requirements, automatically generate the QOS and data definition files (usually using XML format instead of IDL) that are use in the DDS portion of their systems.

       3. A system that is easily extensible is another goal, how can we introduce another new DDS nodes to the system easily.

       There's almost nothing special that you have to do.  The way that DDS works automatically discovers new DDS nodes and connects to them or discovers existing nodes have gone away (shutdown/crash) and disconnect from them.  System extensibility is one of the main advantage of using DDS.

       In addition, DDS supports eXtensible Type definitions which allows you to define data types that can be modified such that new applications using a modified definition of a data type can still communicate and interoperate with old applications using a previous version of the data type.  You can also read about it here, a blog dated 2014, when RTI first started to support DDS X-Types.