Category Archives: Systems Engineering

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.

Architecture of the engineering organisation

ISSN 2567-6458, 11.April 2019 – 18.February 2021
Email: info@uffmm.org
Author: Louwrence Erasmus
Email: louwrence@erasmus.org.za

For many years I had a problem with the enterprise architecture of a business that performs engineering. For the past two decades I was looking for a framework that can clearly show the uniqueness of the architecture of the engineering organisation (AOTEO).

Systems engineers have talked about parts of the architecture for the engineering organisation through the years, by discussing the creating system (a.k.a. designing system [1]) and the created system (a.k.a. system under design [1]). These two systems are embedded into a context system [1] that provides the environment in which the created system must operate in. Thus in IDEF0 notation, the Creating System delivers the Created System:

IDEF0 for Created and Creating Systems

The Creating System is managed through Engineering Management, that includes project management and technology management for the purposes of this discussion, see below:

IDEF0 for Engineering Management, Creating System and Created System

All the above systems are governed by the Compliance System, see below:

IDEF0 of Compliance, Engineering Management, Created and Creating Systems

The Engineering Enterprise has thus the following high level architecture:

Engineering Enterprise

Created System

The management documents associated with the Created System include, but are not limited to:

  • Manufacturing Plan
  • Delivery Plan
  • Installation and Commissioning Plan
  • Construction Plan
  • Operational Plan
  • Integrated Logistic Support Plan

The compliance for the created system is Quality Assurance. 

Creating System

The management documents typically are, but not limited to:

  • Project Plan
  • Systems Engineering Management Plan
  • Systems Engineering Plan,
  • Engineering Plan,
  • Development Plan,
  • Configuration Management Plan
  • Safety Plan
  • Test Plan

Verification and Validation are the compliance activities for the creating system.

Engineering Management

The management documents are, but not limited to:

  • Business Plan
  • Resource Plan
  • Financial Plan

Governance is the compliance checking for Engineering Management.

Compliance

The typical management documents are:

  • Quality Management Plan
  • Test and Evaluation Management Plan
  • Governance Plan

References

[1] Long, D and Scott, Z (2011) A Primer for Model-Based Systems Engineering, 2nd Edition, Vitech Corporation.

ADVANCED AAI-THEORY

eJournal: uffmm.org,
ISSN 2567-6458, 21.Januar 2019
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

Here You can find a new version of this post

CONTEXT

The last official update of the AAI theory dates back to Oct-2, 2018. Since that time many new thoughts have been detected and have been configured for further extensions and improvements. Here I try to give an overview of all the actual known aspects of the expanded AAI theory as a possible guide for the further elaborations of the main text.

CLARIFYING THE PROBLEM

  1. Generally it is assumed that the AAI theory is embedded in a general systems engineering approach starting with the clarification of a problem.
  2. Two cases will be distinguished:
    1. A stakeholder is associated with a certain domain of affairs with some prominent aspect/ parameter P and the stakeholder wants to clarify whether P poses some ‘problem’ in this domain. This presupposes some explained ‘expectations’ E how it should be and some ‘findings’ x pointing to the fact that P is ‘sufficiently different’ from some y>x. If the stakeholder judges that this difference is ‘important’, than P matching x will be classified as a problem, which will be documented in a ‘problem document D_p’. One interpret this this analysis as a ‘measurement M’ written as M(P,E) = x and x<y.
    2. Given a problem document D_p a stakeholder invites some experts to find a ‘solution’ which transfers the old ‘problem P’ into a ‘configuration S’ which at least should ‘minimize the problem P’. Thus there must exist some ‘measurements’ of the given problem P with regard to certain ‘expectations E’ functioning as a ‘norm’ as M(P,E)=x and some measurements of the new configuration S with regard to the same expectations E as M(S,E)=y and a metric which allows the judgment y > x.
  3. From this follows that already in the beginning of the analysis of a possible solution one has to refer to some measurement process M, otherwise there exists no problem P.

CHECK OF FRAMING CONDITIONS

  1. The definition of a problem P presupposes a domain of affairs which has to be characterized in at least two respects:
    1. A minimal description of an environment ENV of the problem P and
    2. a list of so-called non-functional requirements (NFRs).
  2. Within the environment it mus be possible to identify at least one task T to be realized from some start state to some end state.
  3. Additionally it mus be possible to identify at least one executing actor A_exec doing this task and at least one actor assisting A_ass the executing actor to fulfill the task.
  4. For the  following analysis of a possible solution one can distinguish two strategies:
    1. Top-down: There exists a group of experts EXPs which will analyze a possible solution, will test these, and then will propose these as a solution for others.
    2. Bottom-up: There exists a group of experts EXPs too but additionally there exists a group of customers CTMs which will be guided by the experts to use their own experience to find a possible solution.

ACTOR STORY (AS)

  1. The goal of an actor story (AS) is a full specification of all identified necessary tasks T which lead from a start state q* to a goal state q+, including all possible and necessary changes between the different states M.
  2. A state is here considered as a finite set of facts (F) which are structured as an expression from some language L distinguishing names of objects (LIKE ‘d1’, ‘u1’, …) as well as properties of objects (like ‘being open’, ‘being green’, …) or relations between objects (like ‘the user stands before the door’). There can also e a ‘negation’ like ‘the door is not open’. Thus a collection of facts like ‘There is a door D1’ and ‘The door D1 is open’ can represent a state.
  3. Changes from one state q to another successor state q’ are described by the object whose action deletes previous facts or creates new facts.
  4. In this approach at least three different modes of an actor story will be distinguished:
    1. A pictorial mode generating a Pictorial Actor Story (PAS). In a pictorial mode the drawings represent the main objects with their properties and relations in an explicit visual way (like a Comic Strip).
    2. A textual mode generating a Textual Actor Story (TAS): In a textual mode a text in some everyday language (e.g. in English) describes the states and changes in plain English. Because in the case of a written text the meaning of the symbols is hidden in the heads of the writers it can be of help to parallelize the written text with the pictorial mode.
    3. A mathematical mode generating a Mathematical Actor Story (MAS): n the mathematical mode the pictorial and the textual modes are translated into sets of formal expressions forming a graph whose nodes are sets of facts and whose edges are labeled with change-expressions.

TASK INDUCED ACTOR-REQUIREMENTS (TAR)

If an actor story AS is completed, then one can infer from this story all the requirements which are directed at the executing as well as the assistive actors of the story. These requirements are targeting the needed input- as well as output-behavior of the actors from a 3rd person point of view (e.g. what kinds of perception are required, what kinds of motor reactions, etc.).

ACTOR INDUCED ACTOR-REQUIREMENTS (AAR)

Depending from the kinds of actors planned for the real work (biological systems, animals or humans; machines, different kinds of robots), one has to analyze the required internal structures of the actors needed to enable the required perceptions and responses. This has to be done in a 1st person point of view.

ACTOR MODELS (AMs)

Based on the AARs one has to construct explicit actor models which are fulfilling the requirements.

USABILITY TESTING (UTST)

Using the actor as a ‘norm’ for the measurement one has to organized an ‘usability test’ in he way, that a real executing test actor having the required profiles has to use a real assisting actor in the context of the specified actor story. Place in a start state of the actor story the executing test actor has to show that and how he will reach the defined goal state of the actor story. For this he has to use a real assistive actor which usually is an experimental device (a mock-up), which allows the test of the story.

Because an executive actor is usually a ‘learning actor’ one has to repeat the usability test n-times to see, whether the learning curve approaches a minimum. Additionally to such objective tests one should also organize an interview to get some judgments about the subjective states of the test persons.

SIMULATION

With an increasing complexity of an actor story AS it becomes important to built a simulator (SIM) which can take as input the start state of the actor story together with all possible changes. Then the simulator can compute — beginning with the start state — all possible successor states. In the interactive mode participating actors will explicitly be asked to interact with the simulator.

Having a simulator one can use a simulator as part of an usability test to mimic the behavior of an assistive actor. This mode can also be used for training new executive actors.

A TOP-DOWN ACTOR STORY

The elaboration of an actor story will usually be realized in a top-down style: some AAI experts will develop the actor story based on their experience and will only ask for some test persons if they have elaborated everything so far that they can define some tests.

A BOTTOM-UP ACTOR STORY

In a bottom-up style the AAI experts collaborate from the beginning with a group of common users from the application domain. To do this they will (i) extract the knowledge which is distributed in the different users, then (ii) they will start some modeling from these different facts to (iii) enable some basic simulations. This simple simulation (iv) will be enhanced to an interactive simulation which allows serious gaming either (iv.a) to test the model or to enable the users (iv.b) to learn the space of possible states. The test case will (v) generate some data which can be used to evaluate the model with regard to pre-defined goals. Depending from these findings (vi) one can try to improve the model further.

THE COGNITIVE SPACE

To be able to construct executive as well as assistive actors which are close to the way how human persons do communicate one has to set up actor models which are as close as possible with the human style of cognition. This requires the analysis of phenomenal experience as well as the psychological behavior as well as the analysis of a needed neuron-physiological structures.

STATE DYNAMICS

To model in an actor story the possible changes from one given state to another one (or to many successor states) one needs eventually besides explicit deterministic changes different kinds of random rules together with adaptive ones or decision-based behavior depending from a whole network of changing parameters.

LIBRARIES AS ACTORS. WHAT ABOUT THE CITIZENS?

eJournal: uffmm.org, ISSN 2567-6458, 19.Januar 2019
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

In this blog a new approach to the old topic of ‘Human-Machine Interaction (HMI)’ is developed turning the old Human-Machine dyad into the many-to-many relation of ‘Actor-Actor Interaction (AAI)’. And, moreover, in this new AAI approach the classical ‘top-down’ approach of engineering is expanded with a truly ‘bottom-up’ approach locating the center of development in the distributed knowledge of a population of users assisted by the AAI experts.

PROBLEM

From this perspective it is interesting to see how on an international level the citizens of a community/ city are not at the center of research, but again the city and its substructures – here public libraries – are called ‘actors’ while the citizens as such are only an anonymous matter of driving these structures to serve the international ‘buzz word’ of a ‘smart city’ empowered by the ‘Internet of Things (IoT)’.

This perspective is published in a paper from Shannon Mersand et al. (2019) which reviews all the main papers available focusing on the role of public libraries in cities. It seems – I could not check by myself the search space — that the paper gives a good overview of this topic in 48 cited papers.

The main idea underlined by the authors is that public libraries are already so-called ‘anchor institutions’ in a community which either already include or could be extended as “spaces for innovation, collaboration and hands on learning that are open to adults and younger children as well”. (p.3312) Or, another formulation “that libraries are consciously working to become a third space; a place for learning in multiple domains and that provides resources in the form of both materials and active learning opportunities”. (p.3312)

The paper is rich on details but for the context of the AAI paradigm I am interested only on the general perspective how the roles of the actors are described which are identified as responsible for the process of problem solving.

The in-official problem of cities is how to organize the city to respond to the needs of its citizens. There are some ‘official institutions’ which ‘officially’ have to fulfill this job. In democratic societies these institutions are ‘elected’. Ideally these official institutions are the experts which try to solve the problem for the citizens, which are the main stakeholder! To help in this job of organizing the ‘best fitting city-layout’ there exists usually at any point of time a bunch of infrastructures. The modern ‘Internet of Things (IoT)’ is only one of many possible infrastructures.

To proceed in doing the job of organizing the ‘best fitting city-layout’ there are generally two main strategies: ‘top-down’ as usual in most cities or ‘bottom-‘ in nearly no cities.

In the top-down approach the experts organize the processes of the cities more or less on their own. They do not really include the expertise of their citizens, not their knowledge, not their desires and visions. The infrastructures are provided from a birds perspective and an abstract systems thinking.

The case of the public libraries is matching this top-down paradigm. At the end of their paper the authors classify public libraries not only as some ‘infrastructure’ but “… recognize the potential of public libraries … and to consider them as a key actor in the governance of the smart community”. (p.3312) The term ‘actor’ is very strong. This turns an institution into an actor with some autonomy of deciding what to do. The users of the library, the citizens, the primary stakeholder of the city, are not seen as actors, they are – here – the material to ‘feed’ – to use a picture — the actor library which in turn has to serve the governance of the ‘smart community’.

DISCUSSION

Yes, this comment can be understood as a bit ‘harsh’ because one can read the text of the authors a bit different in the sense that the citizens are not only some matter to ‘feed’ the actor library but to see the public library as an ‘environment’ for the citizens which find in the libraries many possibilities to learn and empower themselves. In this different reading the citizens are clearly seen as actors too.

This different reading is possible, but within an overall ‘top-down’ approach the citizens as actors are not really included as actors but only as passive receivers of infrastructure offers; in a top-down approach the main focus are the infrastructures, and from all the infrastructures the ‘smart’ structures are most prominent, the internet of things.

If one remembers two previous papers of Mila Gascó (2016) and Mila Gascó-Hernandez (2018) then this is a bit astonishing because in these earlier papers she has analyzed that the ‘failure’ of the smart technology strategy in Barcelona was due to the fact that the city government (the experts in our framework) did not include sufficiently enough the citizens as actors!

From the point of view of the AAI paradigm this ‘hiding of the citizens as main actors’ is only due to the inadequate methodology of a top-down approach where a truly bottom-up approach is needed.

In the Oct-2, 2018 version of the AAI theory the bottom-up approach is not yet included. It has been worked out in the context of the new research project about ‘City Planning and eGaming‘  which in turn has been inspired by Mila Gascó-Hernandez!

REFERENCES

  • S.Mersand, M. Gasco-Hernandez, H. Udoh, and J.R. Gil-Garcia. “Public libraries as anchor institutions in smart communities: Current practices and future development”, Proceedings of the 52nd Hawaii International Conference on System Sciences, pages 3305 – 3314, 2019. URL https: //hdl.handle.net/10125/59766 .

  • Mila Gascó, “What makes a city smart? lessons from Barcelona”. 2016 49th Hawaii International Conference on System Sciences (HICSS), pages 2983–2989, Jan 2016. D O I : 10.1109/HICSS.2016.373.

  • Mila Gascó-Hernandez, “Building a smart city: Lessons from Barcelona.”, Commun. ACM, 61(4):50–57, March 2018. ISSN 0001-0782. D O I : 10.1145/3117800. URL http://doi.acm.org/10.1145/3117800 .

AASE – Actor-Actor Systems Engineering. Theory & Applications. Micro-Edition (Vers.9)

eJournal: uffmm.org, ISSN 2567-6458
13.June  2018
Email: info@uffmm.org
Authors: Gerd Doeben-Henisch, Zeynep Tuncer,  Louwrence Erasmus
Email: doeben@fb2.fra-uas.de
Email: gerd@doeben-henisch.de

PDF

CONTENTS

1 History: From HCI to AAI …
2 Different Views …
3 Philosophy of the AAI-Expert …
4 Problem (Document) …
5 Check for Analysis …
6 AAI-Analysis …
6.1 Actor Story (AS) . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Textual Actor Story (TAS) . . . . . . . . . . . . . . .
6.1.2 Pictorial Actor Story (PAT) . . . . . . . . . . . . . .
6.1.3 Mathematical Actor Story (MAS) . . . . . . . . . . .
6.1.4 Simulated Actor Story (SAS) . . . . . . . . . . . . .
6.1.5 Task Induced Actor Requirements (TAR) . . . . . . .
6.1.6 Actor Induced Actor Requirements (UAR) . . . . . .
6.1.7 Interface-Requirements and Interface-Design . . . .
6.2 Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Actor and Actor Story . . . . . . . . . . . . . . . . .
6.2.2 Actor Model . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Actor as Input-Output System . . . . . . . . . . . .
6.2.4 Learning Input-Output Systems . . . . . . . . . . . .
6.2.5 General AM . . . . . . . . . . . . . . . . . . . . . .
6.2.6 Sound Functions . . . . . . . . . . . . . . . . . . .
6.2.7 Special AM . . . . . . . . . . . . . . . . . . . . . .
6.2.8 Hypothetical Model of a User – The GOMS Paradigm
6.2.9 Example: An Electronically Locked Door . . . . . . .
6.2.10 A GOMS Model Example . . . . . . . . . . . . . . .
6.2.11 Further Extensions . . . . . . . . . . . . . . . . . .
6.2.12 Design Principles; Interface Design . . . . . . . . .
6.3 Simulation of Actor Models (AMs) within an Actor Story (AS) .
6.4 Assistive Actor-Demonstrator . . . . . . . . . . . . . . . . . .
6.5 Approaching an Optimum Result . . . . .
7 What Comes Next: The Real System
7.1 Logical Design, Implementation, Validation . . . .
7.2 Conceptual Gap In Systems Engineering? . . .
8 The AASE-Paradigm …
References

Abstract

This text is based on the the paper “AAI – Actor-Actor Interaction. A Philosophy of Science View” from 3.Oct.2017 and version 11 of the paper “AAI – Actor-Actor Interaction. An Example Template” and it   transforms these views in the new paradigm ‘Actor- Actor Systems Engineering’ understood as a theory as well as a paradigm for and infinite set of applications. In analogy to the slogan ’Object-Oriented Software Engineering (OO SWE)’ one can understand the new acronym AASE as a systems engineering approach where the actor-actor interactions are the base concepts for the whole engineering process. Furthermore it is a clear intention to view the topic AASE explicitly from the point of view of a theory (as understood in Philosophy of Science) as well as from the point of view of possible applications (as understood in systems engineering). Thus the classical term of Human-Machine Interaction (HMI) or even the older Human-Computer Interaction (HCI) is now embedded within the new AASE approach. The same holds for the fuzzy discipline of Artificial Intelligence (AI) or the subset of AI called Machine Learning (ML). Although the AASE-approach is completely in its beginning one can already see how powerful this new conceptual framework  is.

 

 

AAI – Actor-Actor Interaction. A Philosophy of Science View

AAI – Actor-Actor Interaction.
A Philosophy of Science View
eJournal: uffmm.org, ISSN 2567-6458

Gerd Doeben-Henisch
info@uffmm.org
gerd@doeben-henisch.de

PDF

ABSTRACT

On the cover page of this blog you find a first general view on the subject matter of an integrated engineering approach for the future. Here we give a short description of the main idea of the analysis phase of systems engineering how this will be realized within the actor-actor interaction paradigm as described in this text.

INTRODUCTION

Overview of the analysis phase of systems engineering as realized within an actor-actor interaction paradigm
Overview of the analysis phase of systems engineering as realized within an actor-actor interaction paradigm

As you can see in figure Nr.1 there are the following main topics within the Actor-Actor Interaction (AAI) paradigm as used in this text (Comment: The more traditional formula is known as Human-Machine Interaction (HMI)):

Triggered by a problem document D_p from the problem phase (P) of the engineering process the AAI-experts have to analyze, what are the potential requirements following from this document, all the time also communicating with the stakeholder to keep in touch with the hidden intentions of the stakeholder.

The idea is to identify at least one task (T) with at least one goal state (G) which shall be arrived after running a task.

A task is assumed to represent a sequence of states (at least a start state and a goal state) which can have more than one option in every state, not excluding repetitions.

Every task presupposes some context (C) which gives the environment for the task.

The number of tasks and their length is in principle not limited, but their can be certain constraints (CS) given which have to be fulfilled required by the stakeholder or by some other important rules/ laws. Such constraints will probably limit the number of tasks as well as their length.

Actor Story

Every task as a sequence of states can be viewed as a story which describes a process. A story is a text (TXT) which is static and hides the implicit meaning in the brains of the participating actors. Only if an actor has some (learned) understanding of the used language then the actor is able to translate the perceptions of the process in an appropriate text and vice versa the text into corresponding perceptions or equivalently ‘thoughts’ representing the perceptions.

In this text it is assumed that a story is describing only the observable behavior of the participating actors, not their possible internal states (IS). For to describe the internal states (IS) it is further assumed that one describes the internal states in a new text called actor model (AM). The usual story is called an actor story (AS). Thus the actor story (AS) is the environment for the actor models (AM).

In this text three main modes of actor stories are distinguished:

  1. An actor story written in some everyday language L_0 called AS_L0 .
  2. A translation of the everyday language L_0 into a mathematical language L_math which can represent graphs, called AS_Lmath.
  3. A translation of the hidden meaning which resides in the brains of the AAI-experts into a pictorial language L_pict (like a comic strip), called AS_Lpict.

To make the relationship between the graph-version AS_Lmath and the pictorial version AS_Lpict visible one needs an explicit mapping Int from one version into the other one, like: Int : AS_Lmath <—> AS_Lpict. This mapping Int works like a lexicon from one language into another one.

From a philosophy of science point of view one has to consider that the different kinds of actor stories have a meaning which is rooted in the intended processes assumed to be necessary for the realization of the different tasks. The processes as such are dynamic, but the stories as such are static. Thus a stakeholder (SH) or an AAI-expert who wants to get some understanding of the intended processes has to rely on his internal brain simulations associated with the meaning of these stories. Because every actor has its own internal simulation which can not be perceived from the other actors there is some probability that the simulations of the different actors can be different. This can cause misunderstandings, errors, and frustrations.(Comment: This problem has been discussed in [DHW07])

One remedy to minimize such errors is the construction of automata (AT) derived from the math mode AS_Lmath of the actor stories. Because the math mode represents a graph one can derive Der from this version directly (and automatically) the description of an automaton which can completely simulate the actor story, thus one can assume Der(AS_Lmath) = AT_AS_Lmath.

But, from the point of view of Philosophy of science this derived automaton AT_AS_Lmath is still only a static text. This text describes the potential behavior of an automaton AT. Taking a real computer (COMP) one can feed this real computer with the description of the automaton AT AT_AS_Lmath and make the real computer behave like the described automaton. If we did this then we have a real simulation (SIM) of the theoretical behavior of the theoretical automaton AT realized by the real computer COMP. Thus we have SIM = COMP(AT_AS_Lmath). (Comment: These ideas have been discussed in [EDH11].)

Such a real simulation is dynamic and visible for everybody. All participating actors can see the same simulation and if there is some deviation from the intention of the stakeholder then this can become perceivable for everybody immediately.

Actor Model

As mentioned above the actor story (AS) describes only the observable behavior of some actor, but not possible internal states (IS) which could be responsible for the observable behavior.

If necessary it is possible to define for every actor an individual actor model; indeed one can define more than one model to explore the possibilities of different internal structures to enable a certain behavior.

The general pattern of actor models follows in this text the concept of input-output systems (IOSYS), which are in principle able to learn. What the term ‘learning’ designates concretely will be explained in later sections. The same holds of the term ‘intelligent’ and ‘intelligence’.

The basic assumptions about input-output systems used here reads a follows:

Def: Input-Output System (IOSYS)

IOSYS(x) iff x=< I, O, IS, phi>
phi : I x IS —> IS x O
I := Input
O := Output
IS := Internal

As in the case of the actor story (AS) the primary descriptions of actor models (AM) are static texts. To make the hidden meanings of these descriptions ‘explicit’, ‘visible’ one has again to convert the static texts into descriptions of automata, which can be feed into real computers which in turn then simulate the behavior of these theoretical automata as a real process.

Combining the real simulation of an actor story with the real simulations of all the participating actors described in the actor models can show a dynamic, impressive process which is full visible to all collaborating stakeholders and AAI-experts.

Testing

Having all actor stories and actor models at hand, ideally implemented as real simulations, one has to test the interaction of the elaborated actors with real actors, which are intended to work within these explorative stories and models. This is done by actor tests (former: usability tests) where (i) real actors are confronted with real tasks and have to perform in the intended way; (ii) real actors are interviewed with questionnaires about their subjective feelings during their task completion.

Every such test will yield some new insights how to change the settings a bit to gain eventually some improvements. Repeating these cycles of designing, testing, and modifying can generate a finite set of test-results T where possibly one subset is the ‘best’ compared to all the others. This can give some security that this design is probably the ‘relative best design’ with regards to T.

Further Readings:

  1. Analysis
  2. Simulation
  3. Testing
  4. User Modeling
  5. User Modeling and AI

For a newer version of the AAi-text see HERE..

REFERENCES

[DHW07] G. Doeben-Henisch and M. Wagner. Validation within safety critical systems engineering from a computation semiotics point of view.
Proceedings of the IEEE Africon2007 Conference, pages Pages: 1 – 7, 2007.
[EDH11] Louwrence Erasmus and Gerd Doeben-Henisch. A theory of the
system engineering process. In ISEM 2011 International Conference. IEEE, 2011.

EXAMPLE

For a toy-example to these concepts please see the post AAI – Actor-Actor Interaction. A Toy-Example, No.1

uffmm – RESTART AS SCIENTIFIC WORKPLACE

RESTART OF UFFMM AS SCIENTIFIC WORKPLACE.
For the Integrated Engineering of the Future (SW4IEF)
Campaining the Actor-Actor Systems Engineering (AASE) paradigm

eJournal: uffmm.org, ISSN 2567-6458
Email: info@uffmm.org

Last Update June-22, 2018, 15:32 CET.  See below: Case Studies —  Templates – AASE Micro Edition – and Scheduling 2018 —

RESTART

This is a complete new restart of the old uffmm-site. It is intended as a working place for those people who are interested in an integrated engineering of the future.

SYSTEMS ENGINEERING

A widely known and useful concept for a general approach to the engineering of problems is systems engineering (SE).

Open for nearly every kind of a possible problem does a systems engineering process (SEP) organize the process how to analyze the problem, and turn this analysis into a possible design for a solution. This proposed solution will be examined by important criteria and, if it reaches an optimal version, it will be implemented as a real working system. After final evaluations this solution will start its carrier in the real world.

PHILOSOPHY OF SCIENCE

In a meta-scientific point of view the systems engineering process can become itself the object of an analysis. This is usually done by a discipline called philosophy of science (PoS). Philosophy of science is asking, e.g., what the ‘ingredients’ of an systems-engineering process are, or how these ingredients do interact? How can such a process ‘fail’? ‘How can such a process be optimized’? Therefore a philosophy of science perspective can help to make a systems engineering process more transparent and thereby supports an optimization of these processes.

AAI (KNOWN AS HMI, HCI …)

A core idea of the philosophy of science perspective followed in this text is the assumption, that a systems engineering process is primarily based on different kinds of actors (AC) whose interactions enable and direct the whole process. These assumptions are also valid in that case, where the actors are not any more only biological systems like human persons and non-biological systems called machines, but also in that case where the traditional machines (M) are increasingly replaced by ‘intelligent machines (IM)‘. Therefore the well know paradigm of human-machine interaction (HMI) — or earlier ‘human-computer interaction (HCI)’  will be replaced in this text by the new paradigm of Actor-Actor Interaction (AAI). In this new version the main perspective is not the difference of man on one side and machines on the other but the kind of interactions between actors of all kind which are necessary and possible.

INTELLIGENT MACHINES

The  concept of intelligent machines (IM) is understood here as a special case of the general Actor (A) concept which includes as other sub-cases biological systems, predominantly humans as instantiations of the species Homo Sapiens. While until today the question of biological intelligence and machine intelligence is usually treated separately and differently it is intended in this text to use one general concept of intelligence for all actors. This allows then more direct comparisons and evaluations. Whether biological actors are in some sense better than the non-biological actors or vice versa can seriously only be discussed when the used concept of intelligence is the same.

ACTOR STORY AND ACTOR MODELS

And, as it will be explained in the following sections, the used paradigm of actor-actor interactions uses the two main concepts of actor story (AS) as well as actor model (AM). Actor models are embedded in the actor stories. Whether an actor model describes biological or non-biological actors does not matter. Independent of the inner structures of an actor model (which can be completely different) the actor story is always  completely described in terms of observable behavior which are the same for all kinds of actors (Comment: The major scientific disciplines for the analysis of behavior are biology, psychology, and sociology).

AASE PARADIGM

In analogy to the so-called ‘Object-Oriented (OO) approach in Software-Engineering (SWE)’ we campaign here the ‘Actor-Actor (AA) Systems Engineering (SE)’ approach. This takes the systems Engineering approach as a base concepts and re-works the whole framework from the point of view of the actor-actor paradigm.  AASE is seen here as a theory as well as an   domain of applications.

Ontologies of the AASE paradigm
Figure: Ontologies of the AASE paradigm

To understand the different perspectives of the used theory it can help to the figure ‘AASE-Paradigm Ontologies’. Within the systems engineering process (SEP) we have AAI-experts as acting actors. To describe these we need a ‘meta-level’ realized by a ‘philosophy of the actor’. The AAI-experts themselves are elaborating within an AAI-analysis an actor story (AS) as framework for different kinds of intended actors. To describe the inner structures of these intended actors one needs different kinds of ‘actor models’. The domain of actor-model structures overlaps with the domain of ‘machine learning (ML)’ and with ‘artificial intelligence (AI)’.

SOFTWARE

What will be described and developed separated from these theoretical considerations is an appropriate software environment which allows the construction of solutions within the AASE approach including e.g. the construction of intelligent machines too. This software environment is called in this text emerging-mind lab (EML) and it will be another public blog as well.

 

THEORY MICRO EDITION & CASE STUDIES

How we proceed

Because the overall framework of the intended integrated theory is too large to write it down in one condensed text with  all the necessary illustrating examples we decided in Dec 2017 to follow a bottom-up approach by writing primarily case studies from different fields. While doing this we can introduce stepwise the general theory by developing a Micro Edition of the Theory in parallel to the case studies. Because the Theory Micro Edition has gained a sufficient minimal completeness already in April 2018 we do not need anymore a separate   template for case studies. We will use the Theory Micro Edition  as  ‘template’ instead.

To keep the case studies readable as far as possible all needed mathematical concepts and formulas will be explained in a separate appendix section which is central for all case studies. This allows an evolutionary increase in the formal apparatus used for the integrated theory.

THEORY IN A BOOK FORMAT

(Still not final)

Here you can find the actual version of the   theory which will continuously be updated and extended by related topics.

At the end of the text you find a list of ToDos where everybody is invited to collaborate. The main editor is Gerd Doeben-Henisch deciding whether the proposal fits into the final text or not.

Last Update 22.June 2018

Philosophy of the Actor

This sections describes basic assumptions about the cognitive structure of the human AAI expert.

From HCI to AAI. Some Bits of History

This sections describes main developments in the history from HCI to AAI.

SCHEDULE 2018

The Milestone for a first outline in a book format has been reached June-22, 2018. The   milestone for a first final version   is  scheduled   for October-4, 2018.