Trees, Forests, Vines.

My current clients are using Model Driven Development for a new product line. Obviously I'm not able to say what the product line is, but that doesn't matter for the work I have to do, which to do with issues they are having working with model consistency between distributed teams on three sites. It actually is quite close in spirit to a project on hypertext repositories for multi-view engineering models I started and couldn't get continued funding for when I was a research associate at York.

They have a large UML/SysML and Simulink model which they are trying to maintain traceablitily. The UML model is created in Enterprise Architect and shared between teams using XMI export and a ClearCase repository. They have modelled their requirements in EA, and are tracing these system requirements to requirements in each sub-system, and from these local requirements to the implementation. They aren't using separate domain and implementation models as is practiced in some UML styles.

EA has a rather awkward XMI import mechanism when it comes to links between elements in different packages - when a package is imported, all links where the client end is in the imported package are erased, and all links defined in the XMI are created. Links are only created if both the client and supplier end exist in the model. This means that unless an inter-package link is recorded in the XMI at both ends, a link created to a new element might not get imported correctly, and so disappear from the XMI next time it is committed to ClearCase.

There are work-arounds for this, but basically the problem comes down to a mis-match between a hierarchical version control system, where users work on a package and the contents of a package, and a hyperlinked model, where links can exist between different nodes in the hierarchy, and really belong to neither end.

Once you also introduce baselines and viewpoints into such an environment, you get to a state where either you have to restrict the types of links - most UML links are designed so the client is dependent on the supplier, so the semantics are compatibily with the link being recorded in the client's package only - and also order the updates - the supplier must exist in the model before the client is loaded into the model for the link to be created. This makes it harder to update models, and for peer teams to push out baselines - you have to update the models for each subsystem team in an order consistent with any dependencies between the subsystems.

The difficulty in ordering baselines between is mitigated by designing to an interface, as it reduces the dependencies between subsystems, but it does not eliminate them. High integrity systems also have common effects which create dependencies between subsystems which cannot be designed around using interfaces (thermal characteristics, electromagnetic interference, power use, etc), and a model without these has lower predictive value. One technique to get around these dependencies is to apportion a budget for them rather than calculating them, which pushes them up towards the root of the tree. The other is to create a dependent model which is traced to the design model but represents the EM view or the thermal view of the system. So in addition to having vines between the branches of the design tree, there can be a forest of trees which model different aspects of the system.

Having looked at the capabilities - and been a bit hopeful about 'model views' - EA doesn't seem to have anything to support multiple viewpoints on the model. You can't create a second tree based on a different viewpoint, and there isn't a navigation via backward «trace» dependency ( you can create a second tree of packages which trace to the original tree, but navigation to the original requires clicking through dialogs ). EA also doesn't create synthetic nesting or dependency relationships between packages in the tree or packages whose elements depend on each other, which are useful if you have more than one hierarchy in the system. Multiple hierarchies arise when you are dividing a system in different ways - for example a structural view is divided into zones, and a functional view into sub-functions, and sub-systems view into sub-systems.

I have a strong feeling that a distributed model based on XMPP or ATOM protocols between nodes for each team should be good, but that doesn't replace the requirement to externalise the model for baselining or backup using industry standard version control tools or the issues with import into existing UML tools. There is also a distinct difference in view between the idea of 'the model' and 'a model' - having moved awy from CASE systems to distributed C4I systems for a couple of years, there are techniques for working with uncertain data and distributed databases which might be interesting to pursue, but are not going to sell to most engineering organisations large enough to need them - if you don't control the situation, then you use distributed models based on the best information available at a time, and then corrolating information from teams, rather than partitioning a system into a rigid hierarchy and trying to manage updates to that hierarchy. In such a distributed model, different viewpoints do not conflict - there is no one 'true' hierarchy of the system, only whatever hierarchy is useful for the team using that viewpoint - and assertions are made about an object which the owners of the object then choose to confirm or reject as authentic.

Last time I looked at RDF is was still disappointing when it comes to baselining parts of a model - although most triple stores have now got some kind of context or graph ID, there isn't 'native' support for versioning or saying graph X contains Y at version Z, and instead the movement seems to be towards having a graph ID per triple, which doesn't seem very manageable to apply version control to - the model has a few thousand packages, each with a few classes, each with a few members, each of which would require several triples to describe, so would be of the order of one or two million triples to include in each baseline. Baselining on a graph dump would be possible - just dump all the triples in the baseline out to a file and put that in source control - but that moves the mechanics out of the RDF metadata. Doing that with XMI and source control means there is nothing other that diff'ing the XMI files between versions to say what has changed; part of wanting to move to a distributed graph format is to get a difference mechanism which understands that the model is a graph rather than a text file.

Where does the energy for a solar-powered mole scarer come from?

This question was given as an example of a poor science question on the today programme today, as the presenters declared that the answer is obvious to anyone with basic literacy and has nothing to do with science or mathematics.

"For every problem there is a solution which is simple, obvious, and wrong."
— Albert Einstein

Taking this as an example of a solar-powered mole scarer, it consists of a plastic spike, an aluminium stake, a plastic head, what looks like a crystalline silicon solar panel and an unspecified 'sonic device'. It also probably contains a rechargeable battery, as moles are crepuscular, but I'll ignore that as unknown.

Unfortunately the manufacturer doesn't specify the dimensions or weight, so I'll just do a finger in the air guess.

Assuming that it's around 200 mm long, 150mm of 25mm aluminium tube is around 100 grams aluminium (0.6 kg/m for 25mm tube). The plastic I'd estimate at 100 grams, and the solar panel around 80mm square. The sonic device is assumed to be a wound copper speaker or motor rather than piezo electric, given that it's producing subsonic frequencies, probably around 25 grams.

Taking embodied energy as 300 MJ/kg for aluminium, 100 MJ/kg for plastics, and 100 MJ/kg for the sonic device (copper and plastic).

The total energy requirement to produce a PV panel is 1,060 kWh/m², though that is for full systems, and we've already accounted for the plastic case, so assume 600kWh/m² = 2.16 GJ/m².

 
Item            Unit Energy     Quantity        Energy
Solar cell      2,000 MJ/m²     0.0064 m²       14 MJ
Plastic body      200 MJ/kg     0.1 kg          20 MJ
Aluminium stake   300 MJ/kg     0.1 kg          30 MJ
Sonic device      200 MJ/kg     0.025 kg         5 MJ
Total                                           69 MJ

At the moment, none of this embodied energy is likely to have been generated by solar power.

A solar cell that size will deliver around 1.5 watts maximum, and assume a seven year lifecycle and, since we're in northern Europe, a 10% duty cycle ( assuming half the hours a year it averages 20% full power ).

1.5W × (60s × 60 × 24 × 365 ) × 7 × 0.10 = 33MJ

For most small devices which aren't in use every day, a solar panel is closer in net effect to a battery which only works when the sun is shining rather than a power source - like a chemical battery, it has energy put into it in manufacture, and you get the same amount of energy back over its lifespan.

I haven't considered end-of-life costs, but already only a third of the 100MJ energy for the solar powered mole scarer is solar.