Simulation of a Dynamic System Model of Social Cognitive Theory (SCT)

Table of Contents

• Overview

• Software Design

  • Class Diagram
  • Data Flow
  • Solvers

• System Equations of SCT Model

• Scenarios and Results of SCT Model

• Model Predictive Control (MPC)
  • MPC Design
  • MPC Results

• References

OVERVIEW

Social Cognitive Theory (SCT)

Figure 1. Social Cognitive Theory association: Behavior, Environment, and Stimuli. . Source: 3

SOFTWARE DESIGN

To represent the Dynamic Model suggested in 1 and build an adequate simulator, the following steps were considered:

• Use Object Oriented (OO) Design Methodology
• Create a class diagram that represents all classes, interfaces and objects in the system
• Design of Software interfaces forces a "design by contract", making the software reliable, containing "mandatory" method calls.
• Establish a simple data flow
• Verify Python's support for OO (and abstract classes)
• Translate differential equations that represent the model and choose the appropriate method to solve the ordinary differential equations (ODE).
• Plot and log results

Class Diagram

The class diagram below contains all classes and interfaces (abstract classes) designed to build the simulation environment and obtain the desired results.

The class diagram can be divided with the following entities:

• Interfaces: Interfaces are abstract classes (you can not instantiate objects directly from interfaces)  that are used to let the software more flexible and support a plugin architecture.
                      Created Interfaces:
                           IObject: It contains the main (and mandatory) interfaces that "all" objects need to implement
                           IModel: It contains the main (and mandatory) interfaces that "all" models need to implement
                           IControl: It contains the main (and mandatory) interfaces that "all" controls need to implement
                           ISolver: It contains the main (and mandatory) interfaces that "all" solvers need to implement
                           ISystem: It contains the main (and mandatory) interfaces that "all" systems need to implement
                           IObserver: It contains the main (and mandatory) interfaces that "all" observers need to implement
                           IFramework: It contains the main (and mandatory) interfaces that "all" frameworks running in the simulator need to implement
  
  
• Classes: Classes are the basic concept in OO. They offer capabilities like: inheritance, polymorphism, Encapsulation, etc.
                      Created Classes:
                            Object : The main class in the system... "almost" everything is an Object. It "implements" the interface IObject and provides the essential attributes and methods for others classes.
                            Model: Class that implements the interface IModel, allowing the system to load different models (in run-time if necessary).
                            Control: Class that implements the interface IControl, allowing the system to load different controls (in run-time if necessary).
                            LQControl: Linear Quadratic control.
                            NonLinearControl: Class that represents a Non-Linear Control System.
                            Throttle: It represents a vehicle's throttle controller (used in a vehicle simulation example)
                            Solver: Class that implements the interface ISolver, allowing the system to load different solvers (in run-time if necessary).
                            Framework: Class that implements the interface IFramework, allowing the system to load different frameworks (in run-time if necessary).
                            Cue, Behavior, Confidence, Expectancy, Self_Efficacy, Skill: Classes directly associated with the model proposed in 1
                            InternaCue, ExternalCue, ActionCue: Specializations of the class Cue.
                            DecisionFramework : A Specializations of the class Framework
                            HmpcControl: A Specializations of the class Control
                            OdeIntSolver, Lyapunov 4, 5, Riccati 6: Specializations of the class Solver
                            Observer : The base class for the observers
                            StateObserver: Specialized class that contains methods and attributes for state estimatives.
                            KalmanStateObserver 7: An observer specialization implemented as a Kalman Optimal Observer (used to estimate states in certain simulations)
                            StcModel: A Specializations of the class Model. This class, basically, represents the model presented in 1. It contains the system's equations, derivatives, stimuli, etc.
                            Simulation: Class used to create the simulation environment.
                            Simulation Environment and SctSimulation : Specialized simulation environments
                            System: Contains the base system implementation.
                            LTISystem: It represents a Linear time Invariant system.
                            SingleIntegrator: Class that represents a system of single integration problem.
                            DoubleIntegrator: Class that represents a system of double integration problem.
                            SimulationResults: Class used only to contain the results produced by the simulation environment.
                            

Data Flow

The objective in the design of the software data flow was to maintain the simplicity (easy to use an maintain).

Logic Sequence	Python Representation

Choosing ODE Solver

To solve the Ordinary Differential equations. it was used one of many numeric integrator found in the Python library SciPy (https://scipy.org/). The integrator

is known as Variable-Coefficient ODE Solver (VODE) with a Backward Differentiation Formula (BDF) method.

The software architecture allows the utilization of different solvers implemented in Python. To do that, it is only necessary to implement the interface ISolver, instantiate

an object from the implementation class, and add the new object into the simulator.

	http://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.ode.html

Source Code

All the source code and project files are available through the system Bitbucket in the following link:

	https://bitbucket.org/hmontelo/dynamicmodelsct/overview

SYSTEM'S EQUATIONS OF SCT MODEL

The objective here was to represent the differential equations format, names, and indexes very similar to those defined in the article. In that way is easy to read and maintain the code.

Article's ODE Definition 1	Python ODE implementation

SCENARIOS AND RESULTS OF SCT MODEL

Stimuli User Interface

Simulator Running Scenario 1

High Self-Efficacy Context

• Observed Behavior = 10
• Perceived Social Support = 10
• Internal Cue = Oscillates (0-5) after the 14th day
• Barriers = 2
• External cues = 5 (days 2-5), 5 (days 8-12)

Result:

The result is a considerable increase on the behavior inventory, and as a consequence some internal cues are now present

(example: after a few days walking daily at the same time and one day resting, the individual experiences the internal necessity to walk)

Note: Results in this scenario are similar to the author's results.

Simulator Running Scenario 2

Increasing Self-Efficacy also increases the behavior

• Observed Behavior = 50 (between days: 6-14)
• Perceived Social Support = 50 (between days: 6-14)
• Internal Cue = Oscillates (0-5) after the 14th day
• Barriers = 10 (Except days: 6-14)
• Interpersonal States: Gaussian Distribution
• Environmental Context: Gaussian Distribution

Result:

A change in self-efficacy produce a change in behavior (about 25%) and, modestly, increases the outcome expectancy too.

Simulator Running Scenario 3

Low Self-Efficacy Context

• Skill Training = 3
• Observed Behavior = 5
• Perceived Social Support = 5
• Internal Cue = 5 (between days: 10-12)
• Barriers = 10

Result:

in this scenario, there is a small increase in the behavior, but it decreases when the internal cue is depleted.

Simulator Running Scenario 4

High Self-Efficacy Context, but increasing

• Observed Behavior = 10
• Perceived Social Support = 10
• Internal Cue = Oscillates (0-5) after the 14th day
• Barriers = 2
• External cues = 5 (days 2-5), 5 (days 8-12)
• Integrative Effect to "sustain" the magnitude of the Behavior: τ₄ = 15 (time constant), β₄₆ = 0.9 (outflow)

Result:

Modeling the system with a more integrative effect (τ₄ = 15, β₄₆ = 0.9) involving the Outcome Expectancy, Behavior, and Behavioral Outcomes

make possible to maintain the magnitude of the Behavior.

MODEL PREDICTIVE CONTROL (MPC)

• Model Based on Multi-variable Control
• Optimal Control Law with I/O constraints
• Non-linear control with model mismatch
• Long and Variable Time delay process

MPC DESIGN

Extending the knowledge about the social effects can influence the human decisions, it is presented below a decision framework for inventory

management in a supply chain 8.The model below represents a production inventory system with one inventory and two production

nodes (primary and auxiliary factories) that requires a MPC solution.

In this scenario, Throughput time  θ₁ =θ ′ ₁ +1 = 4 days  and yield K₁ = 0.9 for the primary factory;

The problem considers the costs associated to the auxiliary factory greater than the primary factor.

The starting or shutdown of the auxiliary factory is a function of the demand forecast (d_f (k)) and the Work in Progress (WIP).

For the auxiliary factory, the throughput time  θ ₂ =θ ′ ₂ +1 = 9 days and yield K₂ = 0.8 .

SYSTEM'S EQUATIONS
Article's definition	Python Representation

where:

• d(k) = d_f (k − θ_f)+d_u(k) is the total customer demand.
• u₁(k) represents the starts for the primary production node
• u₂(k) is the starts for the auxiliary production node
• WIP represents the work-in-progress in the primary production node
  
  

	SYSTEM CONSTRAINTS
1
2
3
4

• Constraint 1: In order to ensure that the auxiliary factory is activated if and only if WIP in the primary factory is at its maximum capacity
• Constraint 2: factories starts the production nodes before 200
• Constraint 3: Work in Progress of the primary factor is less or equal to 600
• Constraint 4: Controlled net stock is between 0 and 1000

Although it was developed different solvers (like Lyapunov or Riccati), to calculate this specific MPC problem was used the python library CVXPY.

	www.cvxpy.org/

Note: All source code can be found in the same Bitbucket repository described before.

Goal:

To meet the customer demand d(k) relying on production from the auxiliary factory only when necessary, while maintaining the net stock inventory level at a predefined set point.

MPC Problem:

Optimization Problem:

Scenario(s):

The goal could be achieved manipulating factory starts u₁(k), u₂(k) and compensating forecast demand d_f (k).

For this scenario: Sampling interval of T = 1 day, θ_f = p = 30 days, α_r = 0.9, α_d = 0, f_a = 0.1, penalty weight parameters Q_y = 1, Q_Δu = diag{0 0}, Q_u = Q_d = Q_z = 0,

prediction horizon p = 30 and control horizon m = 25

MPC RESULTS

• Start of factories
  
  
  
  
• Customer demand (red) and Demand forecast (black)

• Net stock response
  
  
  
  
• Work in Progress
  
  

REFERENCES