System Engineering & Design Architecture by Sander R.B.E. Beals (top novels .txt) 📖

Cover and Table of Contents

Table of Contents

Introduction 3

Everything is a System 4

Keep It Simple Sir.... 6

A Higher Note... 11

More Input!.... 14

System Conception 17

System Development by Analogy 19

In your Face! 31

Connecting to the Unknown.... 33

Talking to Friends 35

the Problem Solving System.... 37

Improving the System 41

Redefining the System 42

Where do we go from Here? 46

Language is Key... 47

QL System 49

Qualingo System Software 49

QL usage by Example 50

Appendix A: the Simple Solutions 52

Keep It Simple Sir.... 52

80 / 20 % rule 52

Divide and Conquer 52

Stepwise Refinement 52

Occam's Razor 52

Thinking outside the Box 52

The 7 item rule 52

Appendix B: the Three Laws of Robotics 53

Appendix C: Programming concepts Explained. 54

Artificial Intelligence 54

Genetic Programming 54

CGI: Computer Generated Imagery 54

Model, View, Controller 55

Object Action Principle 55

 

Introduction

An amusing discussion with a colleague the other day made me realize that the last statement on systems design hasn't been uttered yet. We were on opposite ends of an obvious standoff, where he claimed that hardware development and software development were essentially different, and I defended the gut feeling that despite a few differences, there must be a similar (set of) mechanism(s) behind them. In my opinion there should be, because software simply cannot live without hardware, and only simple hardware (like a hammer) can do without software. In order for them to cooperate, there must be a certain 'resonance' in their mutual cooperation. Other than that, they are basically all hybrid systems, with a sometimes delicate mix of mechanical, electrical and software aspects, that need to be designed as a whole to retain overall consistency. In the current timeframe, invasive interfacing to biological systems is seen as a research subject, but I believe that even that will eventually become commonplace. It is just a matter of seeing where we are comfortable with connecting to our tools, like the hand that yields the hammer, the surgical steel replacement parts for bones or the syringe that helps us donate blood to those who need it desperately. And wouldn't it be great if we could have the understanding of a System Engineering and Design Architecture that would be similar (if not identical) for all aspects of Systems Creation?

This document will describe the structure of a system based on the SevenSphere aspect of Nature I became aware of in my efforts to make clear (to me at least) the various aspects of the world my five or six senses perceive around me. The introductory texts can be found in a trilogy of relatively light reading that can be downloaded as public domain information at http://moorelife.nl. The following titles are the ones I am talking about here:

"Infinity plus One", 77 pages in English, part one of the trilogy.

"Art of War once Moore", 50 pages in English, part two.

"LIFE: Love Infinitely Furthers Evolution", 82 pages in English, part three.

This document is not a true sequel to the Trilogy, but more of a textbook for a course on Systems Engineering & Design Architecture for normal (read non-technical) people, Muggle or magical person alike. As for me, I'm just the ordinary guy with a deep interest in observing the simplicity of things for what it really is, and describing it to others in similarly simple concepts.

To sum up the essentials of the SevenSphere for anyone not wanting to read the three books mentioned, the elementary operation is simple: any word written in the gray center sphere can be explained, further defined or refined by six other words in the colored spheres around it, either in a 1x6, 2x3, 3x2, or 6x1 configuration. This is not a rigid mechanism, but a way of working where we simply keep in mind that the human mind is said to not be able to keep track of more than seven concepts at a time. You might consider this as a sort of graph paper for understanding, because the various SevenSpheres can combine to form a virtual hexagonal (honey comb) structure like any of our more complex molecules, which is known to be a very stable structure in Nature (carbon compounds form this way). Either way, it allows us to clearly connect the stuff we talk about. Also, sets of seven usually have one main concept, which plays the central role in a SevenSphere, if it is not 6 defining one...

You'll get the hang of it as I talk you through the first few diagrams, which will make clear that it is a great way of making things clear.... ;-)

Everything is a System

They say: "If you have a hammer, everything becomes a nail." Likewise, this document and its promise of a System Engineering & Design Architecture will turn everything into a System, by simply looking at it through System-colored glasses....

We already established that only fairly simple tools do not require software, just like only the simplest of our everyday technology doesn't use electricity. Most of our Systems are so-called Hybrid Systems, a mix of the following aspects:

Chemical

Material

Mechanical

Electrical (including magnetical)

Computational

Biological (sensory, manipulative and/or invasive)

 

Now describing it in terms of the constituent parts may be a simple thing to do, but with regard to the architecture of the whole it is hardly useful. We do not want to know the parts, but rather how they cooperate to make the whole. And that is quite another subject, given the fact that there are two sides to that whole, the view of the user, and the view of the creators of the system. For the purpose of this document, we must attempt to bring the two together, so the creators can create what the users want, instead of some distorted mirror image of it. But luckily for us, even design is a System. Just look at the SevenSphere below:

In this image, the creators are diagonally across from the users, who should be the ones the creators design their systems for. The users on their part form a stable triangle with the devices and interfaces they employ to use the system. They don't care which part is hardware and which is software! That is the realm of the creators: they know both the problem space and the solution space, and have the skills to realize a solution using specific combinations of these aspects to get things done. They may even have to go as far as to design a completely different system first, in order to get the user what he or she wants. Just think of the cell phone system: it has phones which the users use, and which interact with local cell towers that are only partially in the awareness of the users. Users may know they are there, but they are usually not able to tell you just how the connection between any two cell phones is made: that is an internal interface, known to the creators and implicitly trusted by the users. The one device users do bother with are their cell phones, and the interfaces on them:

the charging port, for when the battery is drained.

the SIM slot to connect their number to the phone.

The MicroSD slot to enhance its memory capacity.

The headphone jack to listen without disturbing others.

the keys that have certain functions, as the software assigns them.

The screen, which can give you pretty much any interface, if it has touch capability.

 

They may of course bother with the more technical interfaces of the phone too, but only if there is a need for it. So battery replacement, network connections, GPS capability, and other related stuff shouldn't be on the outside. Still, they are points of attention to both the creators and the users, and they show how interfaces are what connects both systems on the outside, as well as subsystems to the system under observation. I'll leave the exercise of creating a SevenSphere of the interfaces, both external and internal, to the users. Remember, this is an intuitive tool, so don't think about it too much... (and don't worry if it doesn't fit perfectly)

Since we're talking about Systems though, let's try and turn one into six terms that define a seventh:

First is the Environment, or the larger picture that the System finds itself in. Based on the Environment, the Strategy may for a large part be aimed at surviving in this Environment. Since this is usually the most dangerous part to a system, let's put it in the red sphere.

Interfaces form distinct communication or logistic lines to specific other (groups of) Systems. These interfaces may lead to outside systems in the environment, or to subsystems inside the System.

Subsystems are those parts of a System that it knows it can rely on because they are embed-ded in the system as such. Apart from their role in sustaining the system we are discussing, the subsystems have no reason to exist on their own, and often they even cannot do so.

Strategy is the Modus Operandi which the System and its Subsystems employ to fulfill their Intention (either assigned or freely chosen), and to maintain Integrity. Asimov framed these beautifully in his three robot laws (see App. B if you are curious, or no Sci Fi geek).

With our Integrity guaranteed by the above, we can proceed towards our Intention, and the development of more Interfaces if needed. Now these may be designed during the design process, or as the System is deployed, and found lacking in certain areas. Nowadays we will fill this with a change request, and engineers adding the missing functionality from 'outside', but in the future Systems may well become self-improving, in that they adapt their configuration to develop missing interfaces on their own. What I mean is this: if we could figure out how to make them, won't they eventually match our intelligence, or even surpass it? Nothing to fear though, just an exciting possibility of today's Status Quo.

In order to maintain Integrity, a System might well have a distinct Strategy to check up on itself every now and then, in order to call out for backup: just think of your phone again, complaining that its battery is nearing depletion. More advanced solutions to this might be to find a power source themselves, like for instance seeping off energy received from local cell phone towers in order to recharge the batteries. Another nice addition to a cell phone would be a few solar cells on the backplane,