Four common scenarios (such as very large DBDOC builds) that will benefit from NEW sibling projects.

Sibling projects! Strange term. What does it mean?

New in DBDOC 10.6, the new "sibling projects" framework allows you to include configuration information from related projects in your build, without including all the documents and graphics from that project.

Here are a number of use cases:

1. Multiple Composer (and WinCAD) Projects - Build separate projects, each with the local console and still have the benefit of DBDOC checking for the existence and type of the imported blocks and tags from others projects. Relevant to people with multiple plants that have interconnections. Makes full checking possible without combining the projects into one DBDOC build, thereby including much more than is wanted for Unit 3 or Recaust area.
2. Huge Systems - We have some systems that are so big that they cannot be built into a single DBDOC project anyhow. This feature allows each large project to check blocks sourced in the other projects properly for the first time.
3. Development Projects - Build a small development project for one or more modules with the main project as a sibling project. This will give you full checking of imported blocks and tags from the rest of the system while making your limited build very quick.
4. AutoCAD Systems - Now, by building sibling projects, your build may be able to include all the AutoCAD files for an area, instead of a compromise being required because you would be building too much into one project.
5. Integrity Check for New Work - Now, you can give a contractor MASTER.DB from the main project (or projects) and let the error checking serve you so you get a tighter project done for you.

Upsides:

1. Faster, Smaller DBDOC Builds
2. DBDOC Builds Focused on Plant Areas
3. Cross-Checking Huge Projects
4. Including More AutoCAD Files
5. Integrity Check for New Work

Downsides:

1. Iteration might be necessary if interacting changes are simultaneously brought into your DBDOC builds. That is, if Project A imports new blocks from Project B, you might not pick them up when you do the first build, because the checking is done against the old build. The workaround is to build projects with changed configurations before the ones that have not changed, or rebuild if you have messages you do not expect to see.
2. "Stub modules" might have to be taken into account where some form of a module configured in another project is included in the one being built. This has been done in projects in the past where references were needed, but the actual configuration that had been cloned was not the master one.
3. Right now, our PCUMAP feature needs a full plant build to show all interactions. We intend to remove that limitation. For now, to get the full PCUMAP feature, just continue building the Composer (or WinCAD) projects without worrying about tags and graphics.
4. You need to open up the small projects with Hyperview to look at the details. The point of sibling projects is to have a nice plant focus to the DBDOC project, while ensuring interactions among projects are cross-checked. 

 

Operating / Conversion Parameters:

 

To make the feature easily available to people, we made the following decisions:

 

1. We include existing files as sibling projects as the default
2. If you have individual projects plus a plant master project, do not include the plant master project as a sibling
3. You must build projects individually, because master.db file is not available to any other project when a build is going on
4. You should review any blocks with external sources to make sure you need them now and to mark them not to have live data fetched

How to Define a Sibling Project - Single Large Project

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects all in a single large plant DBDOC project.

 

Create a new project for Loop 1. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is selected. Go ahead and build.

 

Any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now create projects for the others, one at time. Mark the previously created small projects as siblings, plus the large one, until you have done the last one.

 

When all small projects are created, use BuildPlus / Tools / Project Options / Define Blocks With External Sources to de-select the large project. From now on, each small project will check the others.

 

How to Define a Sibling Project - Existing Decoupled Small Projects

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects in their own individual project. You might also have a single large plant DBDOC project.

 

Open up the project for Loop 1 in BuildPlus. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is NOT selected, but that the other small projects are marked as "siblings". Go ahead and build.

 

Again, any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now modify the other projects in the same way. When you are done, you will find that "no source" messages may have disappeared. Also, if they have, you can be confident in the fact that DBDOC has probably found the PV, SP and MA blocks for station tags properly. This will be an improvement of significance.

 

How to Set Up a Development Project

 

Although not a "Holy Grail" in INFI 90, we have often been asked to support DBDOC builds for development work. Now it can be done reasonably.

 

In the case of work being done in the main Composer project, the development DBDOC project would involve the following:

• Build the main project excluding the modules under development to keep on top of imported blocks and tags from the development work
• Build only the modules being worked on in the development project, using the same Composer project and use the main project as the sibling
• Rebuild the main project with the development project as sibling if this is useful.

If the Composer work is being done in a separate project, simply make it into a DBDOC project with the main project as its sibling project.

 

The Biggest Systems in the World

 

When multiple projects exist that cannot be built within the limitation of about 20,000 documents and 2 GB DBDOC M14 file size, the technique is trivial and very valuable. Simply mark the other projects as siblings. Most "no source" messages will disappear and you will be left with the errors that could bite you.