It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787

question asked: Oct 23 '10, 3:01 a.m.
question was seen: 4,050 times
last updated: Oct 23 '10, 3:01 a.m.

Related questions

FAQ - How this Forum works

Component development - how to do that?

0
Frank Schophuizen (193●2●32●26) | asked Oct 23 '10, 3:01 a.m.
RTC does support components, but how does it support component development. Let me take an example from the systems development domain.

A system consists of hierarchy of components. The High Level Components (HLC) perform intelligent functions and the Low Level Components (LLC) are the drivers to the hardware, such as PLCs, sensors and actuators.

Suppose the system consist of 1000 identical PLCs of type PLC1234, controlled by driver DR1234A and each configured by a (PLC specific) XML file. The system baseline initially contains 1000 XML files and version R1.0 of DR1234A. The system runs 24/7 and very expensive to shut down.

Now a few PLCs need replacement, but PLC1234 is end-of-life and replaced by a new generation PLC1235Z. This requires an update to the driver, resulting in R1.1 of DR1234A. Now the system baseline contains those 1000 XML files, and needs to include both R1.0 and R1.1 of DR1234A. Even more, per PLC it must be configured whether R1.0 or R1.1 of DR1234A is used.

How to organize this in RTC?

Since it is a high availability 24/7 system, it is no option to replace all PLC1234's by PLC1235Z, or the customer does not accept the risks of replacing DR1234A R1.0 by R1.1, except for the malicious PLCs. So, how to make a baseline containing different versions of the same component?

One alternative could be to create a new component for DR1234A (e.g. DR1234B), as a variant of DR1234A rather than a new version of DR1234A. But then, how does RTC manage component variants?. In particular if variants are 99% identical, how to control bugfixing in this common area?

The potential solution for updates to the common part of variants could be to make yet another component containing the "core" of DR1234A. But this is just shifting the problem, since at a certain time we also need variants of this "core" component, which means shifting parts of the core to the variants.

With ClearCase UCM, this use case is also hard to solve, but Synergy (formerly of Telelogic) it is also hard but allows a little more flexibility. If RTC does not allow this either, how would it need to be changed to make it possible in your opinion?

Thank you for thinking with me,
Frank.

Accepted answer

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Oct 23 '10, 5:20 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Ralph,

Variant management is a complicated subject. Probably the most
important thing to recognize is the tension between simple automated
merging and variants. In order to automate merging, you need to have
exactly one object with a given identity, so that when a set of changes
come in, the system can automatically apply them to the "right" objects.
This means that you cannot have two variants of the same object in the
same system, or else automated merging becomes complicated ... whenever
a change came in, the system would have to ask you "which variant(s)
should this change be applied to".

So what do you do about this?

The approach I recommend is to handle variants through the "build
system" rather than through the versioning system. Store all of the
variants in a single object, and use a build step to "extract" the
desired variant from that object. Often, the compiler itself supports
this process through "conditional compilation". If not, you can use a
pre-processor to the compiler to perform this extraction.

Then for the part of your build that produces the drivers for the
PLC1234 machines, you'll use one set of preprocessor flags, while for
the part of your build that produces the drivers for the PL1235Z
machine, use another set of preprocessor flags.

Cheers,
Geoff


On 10/23/2010 3:08 AM, fschop wrote:
RTC does support components, but how does it support component
development. Let me take an example from the systems development
domain.

A system consists of hierarchy of components. The High Level
Components (HLC) perform intelligent functions and the Low Level
Components (LLC) are the drivers to the hardware, such as PLCs,
sensors and actuators.

Suppose the system consist of 1000 identical PLCs of type PLC1234,
controlled by driver DR1234A and each configured by a (PLC specific)
XML file. The system baseline initially contains 1000 XML files and
version R1.0 of DR1234A. The system runs 24/7 and very expensive to
shut down.

Now a few PLCs need replacement, but PLC1234 is end-of-life and
replaced by a new generation PLC1235Z. This requires an update to
the driver, resulting in R1.1 of DR1234A. Now the system baseline
contains those 1000 XML files, and needs to include both R1.0 and
R1.1 of DR1234A. Even more, per PLC it must be configured whether
R1.0 or R1.1 of DR1234A is used.

How to organize this in RTC?

Since it is a high availability 24/7 system, it is no option to
replace all PLC1234's by PLC1235Z, or the customer does not accept
the risks of replacing DR1234A R1.0 by R1.1, except for the malicious
PLCs. So, how to make a baseline containing different
versions of the same component?

One alternative could be to create a new component for DR1234A (e.g.
DR1234B), as a variant of DR1234A rather than a new version of
DR1234A. But then, how does RTC manage component
variants?. In particular if variants are 99%
identical, how to control bugfixing in this common area?

The potential solution for updates to the common part of variants
could be to make yet another component containing the
"core" of DR1234A. But this is just shifting the problem,
since at a certain time we also need variants of this
"core" component, which means shifting parts of the core to
the variants.

With ClearCase UCM, this use case is also hard to solve, but Synergy
(formerly of Telelogic) it is also hard but allows a little more
flexibility. If RTC does not allow this either, how
would it need to be changed to make it possible in your
opinion?

Thank you for thinking with me,
Frank.
Frank Schophuizen selected this answer as the correct answer

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.