HMI ANALYSIS, Part 4: Tool based Actor Story Development with Testing and Gaming

Integrating Engineering and the Human Factor (info@uffmm.org)
eJournal uffmm.org ISSN 2567-6458, March 3-4, 2021,
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

Last change: March 4, 2021, 07:49h (Minor corrections; relating to the UN SDGs)

HISTORY

As described in the uffmm eJournal  the wider context of this software project is an integrated  engineering theory called Distributed Actor-Actor Interaction [DAAI] further extended to the Collective Man-Machine Intelligence [CM:MI] paradigm.  This document is part of the Case Studies section.

HMI ANALYSIS, Part 4: Tool based Actor Story Development with Testing and Gaming

Context

This text is preceded by the following texts:

INFO GRAPH

Overview about different scenarios which will be possible for the development, simulation, testing and gaming of actor stories using the oksimo software tool

Introduction

In the preceding post it has been explained, how one can format an actor story [AS] as a theory in the  format  of  an Evaluated Theory Tε with Algorithmic Intelligence:   Tε,α=<M,∑,ε,α>.

In the following text it will be explained which kinds of different scenarios will be possible to elaborate, to simulate, to test, and to enable gaming with  an actor story theory by using the oksimo software tool.

UNIVERSAL TEAM

The classical distinctions between certain types of managers, special experts and the rest of the world is given up here in favor of a stronger generalization: everybody is a potential expert with regard to a future, which nobody knows. This is emphasized by the fact, that everybody can use its usual mother tongue, a normal language, every language. Nothing more is needed.

BASIC MODELS (S, X)

As minimal elements for all possible applications it is assumed here that the experts define at least a given situation (state) [S] and a set of change rules [X].

The given state S is  either (i)  taken as it is or (ii)  as a state which  should be improved. In both cases the initial state S is called the start state [S0].

The change rules X describe possible changes which transform a given state S into a changed successor state S’.

A pair of S and X as (S,X) is called a basic model M(S,X). One can define as many models as one wants.

A DIRECTION BY A VISION V

A vision [V] can describe a possible state SV  in an assumed future. If such a state SV is given, then this state becomes a goal state SGoal In this case  we assume V ≠ 0. If no explicit goal is given, then we assume V = 0.

DEVELOPMENT BY GOALS

If a vision is given (V ≠ 0), then the vision can be used to induce a direction which can/ shall be approached by creating a set X, which enables the generation of a sequence of states with the start state S0 as first state followed by successor state Si until the goal state SGoal has been reached or at least it holds that the goal state is a subset of the reached state: SGoalSn.

It is possible to use many basic models M(S,X) in parallel and for each model Mi one can define a different goal Vi (the typical situation in a pluralistic society).

Thus there can be many basic theories T(M,V) in parallel.

STEADY STATES (V = 0)

If no explicit visions are defined (V = 0) then every direction of change is allowed. A basic steady state theory T(M,V) with V = 0 can   be written as T(M,0). Whether such a case can be of interest is not clear at the moment.

BASIC INTERACTION PATTERNS

The following interaction modes are assumed as typical cases:

  1. N-1: Within an online session an interactive webpage with the oksimo software is active and the whole group can interact with the oksimo software tool.
  2. N-N-1: N-many participants can individually login into the interactive oksimo website and being logged in they can collaborate within the oksimo software with one project.
  3. N-N-N: N-many participants can individually login into the interactive oksimo website and there everybody can run its own process or can collaborate in various ways.

The default case is case (1). The exact dates for the availability of modes (2) – (3) depends from how fast the roadmap can be realized.

BASIC APPLICATIONS
  1. Exploring Simulation-Based Development [ESBD] (V ≠ 0): If the main goal is to find a path from a given state today S (Now) to an envisioned state V in the future then one has  to collect appropriate change rules X to approach the final goal state SGoal better and better. Activating the simulator ∑ during search and construction phase at will can be of great help, especially if the documents (S, X, V) are becoming more and more complex.
  2. Embedded Simulation-Based  Testing [ESBT] (V ≠ 0): If a basic  actor story theory T(M,) is given with a given goal (V ≠ 0) then it is of great help if the simulation is done in interactive mode where the simulator is not applying the change rules by itself but by asking different logged in users which rule they want to apply and how. These tests show not only which kinds of errors will occur but they can also show during n-many repetitions to which degree an user  can learn to behave task-conform. If the tests will not show the expected outcomes then this can point  to possible deficiencies of the software as well to specialties of the user.
  3. Embedded Simulation-Based Gaming [ESBTG] (V ≠ 0):  The case of gaming is partially  different to the case of testing.  Although it is assumed here too that at least one vision (goal) is given, it is additionally assumed that  there exists  a competition between different players or different teams. Different to testing exists in gaming according to the goal(s) the role of a winner: that player/ team which has reached a defined  goal state before the other player/ teams,  has won. As a side-effect of gaming one can also evaluate the playing environment and give some feedback to the developers.
ALGORITHMIC INTELLIGENCE
  1. Case ESBD, T(S,X,V,∑,ε,α): Because a normal simulation with the simulator always does  produce only one path from the start state to the goal state it is desirable to have an algorithm α which would run on demand as many times as wanted and thereby the algorithm α would search for all possible paths and at the same time it would look for those derivations, where the goal state satisfies with  ε certain special requirements. Thus the result from the application of α onto a given model M with the vision V would generate the set SV* of all those final states which satisfy the special requirements.
  2. Case ESBG, T(S,X,V,∑,ε,α):   The case of gaming allows at least three kinds of interesting applications for algorithmic intelligence: (i) Introduce non-biological players with learning capabilities which can act simultaneously with the biological players; (ii) Introduce non-biological players with learning capabilities which have to learn how to support, to assist, to train biological player. This second case addresses the challenging task to develop algorithmic tutors for several kinds of learning tasks. (iii) Another variant of case (ii) is to enable the development of a personal algorithmic assistant who works only with one person on a long-term basis.

The kinds of algorithmic Intelligence in (2)(i)-(iii) are different to the  mentioned algorithmic intelligence α in (1).

TYPES OF ACTORS

As the default standard case of an actor it is assumed that there are biological actors, usually human persons, which will not be analyzed with their inner structure [IS]. While the behavior of every system — and  therefore any biological system too — can be described with a behavior function φ: I x IS —> IS x O (if one has all the necessary knowledge), in the default case of biological systems  no behavior function φ is specified, φ = 0. During interactive simulations biological systems act by themselves.

If non-biological actors are used — e.g. automata with a certain machine program (an algorithm) — then one can use these only if one has a fully specified behavior function φ. From this follows that a  change rule which is associated with a non-biological actor has in its Eplus and in its Eminus part not a concrete expression but a variable, which will be computed during the simulation by the non-biological actor depending from its input and its behavior function φ: φ(input)IS=(Eplus, Eminus)IS.

FINAL COMMENT

Everybody who has read the parts (1) – (4) has now a general knowledge about the motivation to develop the oksimo software tool to support human kind to have a better communication and thinking of possible futures and a first understanding (hopefully :-)) how this tool can work. Reading the UN sustainable development goals [SDGs] [1] you will learn, that the SDG4 (Ensure inclusive and equitable quality education and promote lifelong learning opportunities for all) is fundamental to all other SDGs. The oksimo software tool is one tool to be of help to reach these goals.

REFERENCES

[1] The 2030 Agenda for Sustainable Development, adopted by all United Nations Member States in 2015, provides a shared blueprint for peace and prosperity for people and the planet, now and into the future. At its heart are the 17 Sustainable Development Goals (SDGs), which are an urgent call for action by all countries – developed and developing – in a global partnership. They recognize that ending poverty and other deprivations must go hand-in-hand with strategies that improve health and education, reduce inequality, and spur economic growth – all while tackling climate change and working to preserve our oceans and forests. See PDF: https://sdgs.un.org/sites/default/files/publication/21252030%20Agenda%20for%20Sustainable%20Development%20web.pdf

[2] UN, SDG4, PDF, Argumentation why the SDG4 ist fundamental for all other SDGs: https://sdgs.un.org/sites/default/files/publications/2275sdbeginswitheducation.pdf

 

 

 

 

 

 

 

 

HMI Analysis for the CM:MI paradigm. Part 3. Actor Story and Theories

Integrating Engineering and the Human Factor (info@uffmm.org)
eJournal uffmm.org ISSN 2567-6458, March 2, 2021,
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

Last change: March 2, 2021 13:59h (Minor corrections)

HISTORY

As described in the uffmm eJournal  the wider context of this software project is an integrated  engineering theory called Distributed Actor-Actor Interaction [DAAI] further extended to the Collective Man-Machine Intelligence [CM:MI] paradigm.  This document is part of the Case Studies section.

HMI ANALYSIS, Part 3: Actor Story and  Theories

Context

This text is preceded by the following texts:

Introduction

Having a vision is that moment  where something really new in the whole universe is getting an initial status in some real brain which can enable other neural events which  can possibly be translated in bodily events which finally can change the body-external outside world. If this possibility is turned into reality than the outside world has been changed.

When human persons (groups of homo sapiens specimens) as experts — here acting as stakeholder and intended users as one but in different roles! — have stated a problem and a vision document, then they have to translate these inevitably more fuzzy than clear ideas into the concrete terms of an everyday world, into something which can really work.

To enable a real cooperation  the experts have to generate a symbolic description of their vision (called specification) — using an everyday language, possibly enhanced by special expressions —  in a way that  it can became clear to the whole group, which kind of real events, actions and processes are intended.

In the general case an engineering specification describes concrete forms of entanglements of human persons which enable  these human persons to cooperate   in a real situation. Thereby the translation of  the vision inside the brain  into the everyday body-external reality happens. This is the language of life in the universe.

WRITING A STORY

To elaborate a usable specification can metaphorically be understood  as the writing of a new story: which kinds of actors will do something in certain situations, what kinds of other objects, instruments etc. will be used, what kinds of intrinsic motivations and experiences are pushing individual actors, what are possible outcomes of situations with certain actors, which kind of cooperation is  helpful, and the like. Such a story is  called here  Actor Story [AS].

COULD BE REAL

An Actor Story must be written in a way, that all participating experts can understand the language of the specification in a way that   the content, the meaning of the specification is either decidable real or that it eventually can become real.  At least the starting point of the story should be classifiable as   being decidable actual real. What it means to be decidable actual real has to be defined and agreed between the participating experts before they start writing the Actor Story.

ACTOR STORY [AS]

An Actor Story assumes that the described reality is classifiable as a set of situations (states) and  a situation as part of the Actor Story — abbreviated: situationAS — is understood  as a set of expressions of some everyday language. Every expression being part of an situationAS can be decided as being real (= being true) in the understood real situation.

If the understood real situation is changing (by some event), then the describing situationAS has to be changed too; either some expressions have to be removed or have to be added.

Every kind of change in the real situation S* has to be represented in the actor story with the situationAS S symbolically in the format of a change rule:

X: If condition  C is satisfied in S then with probability π  add to S Eplus and remove from  S Eminus.

or as a formula:

S’π = S + Eplus – Eminus

This reads as follows: If there is an situationAS S and there is a change rule X, then you can apply this change rule X with probability π onto S if the condition of X is satisfied in S. In that case you have to add Eplus to S and you have to remove Eminus from S. The result of these operations is the new (successor) state S’.

The expression C is satisfied in S means, that all elements of C are elements of S too, written as C ⊆ S. The expression add Eplus to S means, that the set Eplus is unified with the set S, written as Eplus ∪ S (or here: Eplus + S). The expression remove Eminus from S means, that the set Eminus is subtracted from the set S, written as S – Eminus.

The concept of apply change rule X to a given state S resulting in S’ is logically a kind of a derivation. Given S,X you will derive by applicating X the new  S’. One can write this as S,X ⊢X S’. The ‘meaning’ of the sign ⊢  is explained above.

Because every successor state S’ can become again a given state S onto which change rules X can be applied — written shortly as X(S)=S’, X(S’)=S”, … — the repeated application of change rules X can generate a whole sequence of states, written as SQ(S,X) = <S’, S”, … Sgoal>.

To realize such a derivation in the real world outside of the thinking of the experts one needs a machine, a computer — formally an automaton — which can read S and X documents and can then can compute the derivation leading to S’. An automaton which is doing such a job is often called a simulator [SIM], abbreviated here as ∑. We could then write with more information:

S,X ⊢ S’

This will read: Given a set S of many states S and a set X of change rules we can derive by an actor story simulator ∑ a successor state S’.

A Model M=<S,X>

In this context of a set S and a set of change rules X we can speak of a model M which is defined by these two sets.

A Theory T=<M,>

Combining a model M with an actor story simulator enables a theory T which allows a set of derivations based on the model, written as SQ(S,X,⊢) = <S’, S”, … Sgoal>. Every derived final state Sgoal in such a derivation is called a theorem of T.

An Empirical Theory Temp

An empirical theory Temp is possible if there exists a theory T with a group of experts which are using this theory and where these experts can interpret the expressions used in theory T by their built-in meaning functions in a way that they always can decide whether the expressions are related to a real situation or not.

Evaluation [ε]

If one generates an Actor Story Theory [TAS] then it can be of practical importance to get some measure how good this theory is. Because measurement is always an operation of comparison between the subject x to be measured and some agreed standard s one has to clarify which kind of a standard for to be good is available. In the general case the only possible source of standards are the experts themselves. In the context of an Actor Story the experts have agreed to some vision [V] which they think to be a better state than a  given state S classified as a problem [P]. These assumptions allow a possible evaluation of a given state S in the ‘light’ of an agreed vision V as follows:

ε: V x S —> |V ⊆ S|[%]
ε(V,S) = |V ⊆ S|[%]

This reads as follows: the evaluation ε is a mapping from the sets V and S into the number of elements from the set V included in the set S converted in the percentage of the number of elements included. Thus if no  element of V is included in the set S then 0% of the vision is realized, if all elements are included then 100%, etc. As more ‘fine grained’ the set V is as more ‘fine grained’  the evaluation can be.

An Evaluated Theory Tε=<M,,ε>

If one combines the concept of a  theory T with the concept of evaluation ε then one can use the evaluation in combination with the derivation in the way that every  state in a derivation SQ(S,X,⊢) = <S’, S”, … Sgoal> will additionally be evaluated, thus one gets sequences of pairs as follows:

SQ(S,X,⊢∑,ε) = <(S’,ε(V,S’)), (S”,ε(V,S”)), …, (Sgoal, ε(V,Sgoal))>

In the ideal case Sgoal is evaluated to 100% ‘good’. In real cases 100% is only an ideal value which usually will only  be approximated until some threshold.

An Evaluated Theory Tε with Algorithmic Intelligence Tε,α=<M,,ε,α>

Because every theory defines a so-called problem space which is here enhanced by some evaluation function one can add an additional operation α (realized by an algorithm) which can repeat the simulator based derivations enhanced with the evaluations to identify those sets of theorems which are qualified as the best theorems according to some criteria given. This operation α is here called algorithmic intelligence of an actor story AS]. The existence of such an algorithmic intelligence of an actor story [αAS] allows the introduction of another derivation concept:

S,X ⊢∑,ε,α S* ⊆  S’

This reads as follows: Given a set S and a set X an evaluated theory with algorithmic intelligence Tε,α can derive a subset S* of all possible theorems S’ where S* matches certain given criteria within V.

WHERE WE ARE NOW

As it should have become clear now the work of HMI analysis is the elaboration of a story which can be done in the format of different kinds of theories all of which can be simulated and evaluated. Even better, the only language you have to know is your everyday language, your mother tongue (mathematics is understood here as a sub-language of the everyday language, which in some special cases can be of some help). For this theory every human person — in all ages! — can be a valuable  colleague to help you in understanding better possible futures. Because all parts of an actor story theory are plain texts, everybody ran read and understand everything. And if different groups of experts have investigated different  aspects of a common field you can merge all texts by only ‘pressing a button’ and you will immediately see how all these texts either work together or show discrepancies. The last effect is a great opportunity  to improve learning and understanding! Together we represent some of the power of life in the universe.

CONTINUATION

See here.

 

 

 

 

 

 

 

 

HMI Analysis for the CM:MI paradigm. Part 1

Integrating Engineering and the Human Factor (info@uffmm.org)
eJournal uffmm.org ISSN 2567-6458, February 25, 2021
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de
Last change: March 16, 2021 (Some minor corrections)
HISTORY

As described in the uffmm eJournal  the wider context of this software project is an integrated  engineering theory called Distributed Actor-Actor Interaction [DAAI] further extended to the Collective Man-Machine Intelligence [CM:MI] paradigm.  This document is part of the Case Studies section.

HMI ANALYSIS, Part 1
Introduction

Since January 2021 an intense series of posts has been published how the new ideas manifested in the new software published in this journal  can adequately be reflected in the DAAI theoretical framework. Because these ideas included in the beginning parts of philosophy, philosophy of science, philosophy of engineering, these posts have been first published in the German Blog of the author (cognitiveagent.org). This series of posts started with an online lecture for students of the University of Leipzig together with students of the ‘Hochschule für Technik, Wirtschaft und Kultur (HTWK)’ January 12, 2021.  Here is the complete list of posts:

In what follows in this text is an English version of the following 5 posts. This is not a 1-to-1 translation but rather a new version:

HMI Analysis as Part of Systems Engineering
HMI analysis as pat of systems engineering illustrated with the oksimo software
HMI analysis for the CM:MI paradigm illustrated with the oksimo software concept

As described in the original DAAI theory paper the whole topic of HMI is here understood as a job within the systems engineering paradigm.

The specification process is a kind of a ‘test’ whether the DAAI format of the HMI analysis works with this new  application too.

To remember, the main points of the integrated engineering concept are the following ones:

  1. A philosophical  framework (Philosophy of Science, Philosophy of Engineering, …), which gives the fundamentals for such a process.
  2. The engineering process as such where managers and engineers start the whole process and do it.
  3. After the clarification of the problem to be solved and a minimal vision, where to go, it is the job of the HMI analysis to clarify which requirements have to be fulfilled, to find an optimal solution for the intended product/ service. In modern versions of the HMI analysis substantial parts of the context, i.e. substantial parts of the surrounding society, have to be included in the analysis.
  4. Based on the HMI analysis  in  the logical design phase a mathematical structure has to be identified, which integrates all requirements sufficiently well. This mathematical structure has to be ‘map-able’ into a set of algorithms written in  appropriate programming languages running on  an appropriate platform (the mentioned phases Problem, Vision, HMI analysis, Logical Design are in reality highly iterative).
  5. During the implementation phase the algorithms will be translated into a real working system.
Which Kinds of Experts?

While the original version of the DAAI paper is assuming as ‘experts’ only the typical manager and engineers of an engineering process including all the typical settings, the new extended version under the label CM:MI (Collective Man-Machine Intelligence) has been generalized to any kind of human person as an expert, which allows a maximum of diversity. No one is the ‘absolute expert’.

Collective Intelligence

As ‘intelligence’ is understood here the whole of knowledge, experience, and motivations which can be the moving momentum inside of a human person. As ‘collective’  is meant  the situation, where more than one person is communicating with other persons to share it’s intelligence.

Man-Machine Symbiosis

Today there are discussions going around  about the future of man and (intelligent) machines. Most of these discussions are very weak because they are lacking clear concepts of intelligent machines as well of what is a human person. In the CM:MI paradigm the human person (together with all other biological systems)  is seen at the center of the future  (by  reasons based on modern theories of biological evolution) and the  intelligent machines are seen as supporting devices (although it is assumed here to use ‘strong’ intelligence compared to the actual ‘weak’ machine intelligence today).

CM:MI by Design

Although we know, that groups of many people are ‘in principal’ capable of sharing intelligence to define problems, visions, constructing solutions, testing the solutions etc., we know too, that the practical limits of the brains and the communication are quite narrow. For special tasks a computer can be much, much better. Thus the CM:MI paradigm provides an environment for groups of people to do the shared planning and testing in a new way, only using normal language. Thus the software is designed to enable new kinds of shared knowledge about shared common modes of future worlds. Only with such a truly general framework the vision of a sustainable society as pointed out by the United Nations since 1992 can become real.

Continuation

Look here.