Making Philosophy Reality

Why Open Source really needs formal Systems Engineering Tools and Techniques

Intended Audience: The VRENAR and IOTA communities

Open Source Achievements

The Open Source community has achieved some amazing stuff.

Bitcoin and IOTA are some examples.

But it could do even better.

It has to do even better. It has to beat Facebook.

It has to do that if there is ever to be any chance of a people-orientated world system that looks after it’s users, rather than looking to profit from them.

The Race

The truth is, there appears to be a race in progress, where the winner will literally take all.

If Facebook gets there first, we will have a world that has perfected the art of extracting value from ourselves, and the world, with all of the problems we see already in profit driven social media, but just worse. There will be no way out. With that level of control, nothing exists to stop even worldwide law and order itself becoming something driven by the sole urge to profit from all people.

Expressing these kinds of thoughts is already becoming progressively more difficult. Have a look at how many people will have seen and applauded this story, written in their interests. Then see how many people are in Facebook, being profited from, whilst being bombarded by all manner of advertising and promotions.

Would this article stand a chance in Facebook? Of course not.

Already the system has begun to choke down on any suggestions that there might be a better way of doing things. With a worldwide system built only to extract profit, all alternative possibilities will be closed off entirely. That done, any number of mechanisms can be used to shut down open source development. No-one would be able to protest, because protesting does not generate any profit.

Open Source could well be stopped in its tracks.

Stepping up

Open Source has to step it up a notch to win.

It probably needs to win this race to survive.

It has to adopt formal Systems Engineering Techniques, and quick.

These tools and techniques are needed to go “Top-down”, straight from concept to implementation, without having to go through the endless loops of trial-and-error pain, of code evolving upwards to meet user requirements, “From the ground up”.

Just for a change, it needs to adopt the tricks of its adversary to make this one last big leap, to conquer the world of social media.

A particularly effective technique used in commercial large scale Systems Engineering is Model Based Design. This enables the system development to start straight away. By this strategy the system is entirely designed in the form of executable diagrams (UML, SysML, Matlab, Simulink) proceeding top-down from the stakeholder requirements, which are also expressed graphically.

The diagrams are constructed simply by “Wiring” together drag/drop graphical elements. Depending on toolset, most diagram types are executable at any stage, at the press of a button. Graphical elements at the higher levels comprise more abstract conceptual things like Use Cases, Activity diagrams (Flowcharts), and sequence diagrams. At the lower levels, elements comprise more practically implementable subsystems like blocks of machine intelligence, image recognition, and signal processing, in many variations.

The diagrams collectively comprise a complete executable system model in layers of abstraction. Each successive layer is a further phase of development, bundling behavioural and structural elements as subsystems, refined from the more general elements in the layers above. Each layer is tested and de-risked by executing its functionality to confirm it meets the stakeholder requirements, which are graphically traced to it before moving onto the next layer. The modelling toolsets also contain many graphical tools for analysing and testing each diagram during construction.

When the design has fully refined all of the stakeholder requirements, by elaboration into practical corresponding functionality, executable code similar to that produced by hand-coding is generated automatically at the press of a button, from the model.

This gives a working prototype of the system at the hand-coding level, in which all of the behaviour has already been tested against the stakeholder requirements.

The generated code really does hit the ground running.

A complex design will have many thousands of lines of code, which normally take a very long time, including many failed tests to produce by hand.

Model auto-generated code still generally requires some massaging by hand coding, to work towards production quality code, but the total time of this combined with the development time to produce the system model is a fraction of the time it takes to hand-develop code “from the ground upwards”. Also, the code comes ready with graphical user documentation in the form of all of the graphics from the model diagrams.

This formal Systems Engineering development process in industry is referred to in many industry standards and journals as “MBSE” (Model Based Systems Engineering).

Hurdles to MBSE adoption in the Open Source community

The problem of getting MBSE techniques adopted by the open source community is multi-fold. The main barrier is cost.

Commercial seats of some of the toolsets mentioned can be tens of thousands of dollars.

In our current system, it seems crazy to expect Open Source coders to ever be able to stretch to those kinds of costs.

In truth, the toolsets themselves are a product of much large scale software development. Each drag and drop element in an executable modelling toolset is an output of much research and development, carried out by huge teams of Engineers and Researchers over many years of testing and refinement.

What we are actually paying to do in effect, is to reuse that effort. When we drag an element from one of these toolsets onto a page, and drop it into the diagram, we literally just included the executable code of many years of the work of others, in our work.

The technique of Model Based Design is now almost perfect, in that it is now capable of designing and producing entire aircraft software systems, already certificated as flight safe, because the toolsets themselves are certificated as capable of producing flight safe software (See standard DO-178C with model based supplements).

The simplicity and power of this now almost perfect Model Based Systems Software Production methodology is such that all of the software needed for an entire aircraft for example, can be produced by one user, in a matter of weeks, by drawing a system of diagrams.

That job of software production prior to the tools and techniques of model based design would have been many years of development, for maybe thirty or more software engineers.

It follows that the long term future of Open Source is also Model Based. In fact, it depends on it.

Lack of Awareness of Capability

Open source is generally done with little funding. It is quite often voluntary work. Practitioners have virtually no funds to put towards tools or training.

The result is that formal Systems Engineering tools and techniques are scarcely known in Open Source communities, far less owned and used.

Without exposure to the tools, developers have little idea of their capabilities in the right hands.

Investors generally have no awareness of the capabilities either.

Both investors and hand-code developers who might already have some experience in Open Source projects, such as crypto-currencies, find it hard to believe when a model based Systems Engineer such as myself claims to be already well into the development of the top levels of VRENAR System functionality, whilst I do not yet have answers to questions of functionality at the lower, more detailed levels of the system (See recent discussions in the VRENAR discord channel).

The point is that this detail does not yet need to be defined, and should not be defined, until the design of the main body of the system is completed to that point.

But the veiled accusation of my efforts being some kind of scam can be very damaging indeed, especially as these efforts are now in desperate need of funding.

Hence my production of this article.

The main non-proprietary modelling languages (The schemes by which diagrams map to code) are UML and SysML. These are represented and adminstrated by a group known as the Object Management Group (OMG)*.

Perhaps somewhat poetically, this is the same utterance as that made by many coders in long term jobs hand-coding, who never previously knew the meaning of Model Based Design, when they first glimpse the whole capability, and realise all of its implications, their first words are simply; “Oh My God”.

The mud-slinging which follows is generally not pretty, and has to be dealt with effectively.

My advice to such hand-coders and investors in all cases is;

Get with the program.

*I note with pleasure recent news that The IOTA foundation, the main expected source of funding for the preferred token of the VRENAR project, IOTA, is now directly involved with OMG, which is great news. Not long now until the full implications get around the IOTA community. I just hope not too late…

Design Justification

The study of utility as affects the outcomes of Metcalfs law predictions leads us to the following:

Although Bitcoin is a large system in terms of the number of users, it is not a large system in terms of complexity. In fact, it is a very simple system, with one simple use case. It required virtually no System Design, and requires little Systems Engineering techniques to maintain it, in our estimation.

The single use case means it also has low utility. This is reflected by a relatively small number of users in the world. It has around 7.1 million users, which is around one in a thousand of the world’s population using it.

Compare that with Facebook. It has around 2.3 billion users, which is around one third of the world’s population using it.

Facebook has a large number of Use cases, and strives to add more, as we see from the purchase of VR company Oculus Rift in 2014, and the announcement this year of the planned introduction of a new Facebook token.

In short, VRENAR needs to have all of the capability of Facebook, because facebook appears to be adopting all of the AR VR capability originally intended in VRENAR.

This is with one exception, Facebook does not appear to include a shared virtual world, which is crucial for realising the value added to the world by users.

Since Facebook has no requirement to similarly reward users, it has no similar requirement to have a shared virtual world.

Most users will likely initially perceive the Facebook token as having similar functionality to Bitcoin.

In that, they will very likely be mistaken, because the currency within any environment designed and built to profit from users is a completely different animal from an open source non-profit crypto-currency such as Bitcoin and IOTA.

Facebook for certain now will use the most advanced Systems Engineeering tools and techniques available to manage its complexity.

The only way to compete with it is to create an alternative system with even more utility. To get the same system utility in the time left, MBSE is needed.

The final part of the additional utility needed, the silver bullet, is the ability to be able to monetise and directly reward the networked human value of the users, directly to the users, individually. That characteristic would represent a very high value of utility, despite it being only a single Use Case.

Ironically, understanding how that can be possible, requires in depth knowledge of the system conceptual design, which only exists in the model.

Design Status

As yet, I have been unable to express that part of the system in any other way than in the model.

There is a document which I have underway in Medium titled “Application of Metcalfs law to VRENAR”.

The document was created around the beginning of this year to capture the essence of how that part of the system functionality works, for the benefit of the intended funders, the IOTA foundation, to justify putting some token capital in VRENAR.

The intended justification is a detailed explanation of how infinite user rewards stack up economically according to Metcalfs law; how this actually works in the system, and how much token capital is needed to light the touch paper.

I believe a neural network controller is needed to control the level of user rewards, in order to maintain the initial market value of the token capital transferred from IOTA for that purpose, over the longer term.

The system is heavily non-linear, and possibly recursive, because the utility is related to the level of user reward, which is part of the calculation of the the network valuation by Metcalfs law.

So a neural network, the “System Ai” is in the System Design Model.

A further “Personal Ai” is in the model, per user, to evaluate the users individual reward.

As yet, it is learning the characteristics of the system, to learn how to control it, whilst I myself am also learning the best form of neural network to use, and even how to teach it, as this is the first time I have had any reason to employ machine intelligence in any system.

Following the successful testing of the system Ai, effort will move onto training personal Ai, per the top down methodology as explained earlier.