Modeling a Fitness Watcher

This example shows a simple model of a Fitness Watcher that uses duration keyword (new in 2017a) in Stateflow®. This example also demonstrates a workflow to build a Stateflow® model that can co-simulate with the app designed using the MATLAB® App Designer.

Model Introduction

The fitness watcher in this model has four parts. Human Simulator is a subsystem modeling your activity, and outputs signals like your heart rate and speed. Fitness Watcher is a Stateflow® chart modeling the core logic, such as how to determine your status and when to send out different useful notifications. UI Controller is a Stateflow® chart that talks to the graphical user interface (GUI). The last part is an app designed with MATLAB® App Designer, which is responsible for GUI implementation and callback definition.

Fitness Watcher Logic Design

The Fitness Watcher chart controls the output of the fitness watch. This chart receives inputs from the subsystem Human Simulator, where the heart rate and speed are calculated. It also receives inputs from the GUI Setting panel, for parameters such as how soon to remind the person for some exercise. Then the chart determines the activity of the person. As the inputs from Human Simulator actively change, the detected activity also changes. This transitional process filters out signal noises by using the new duration keyword. For instance, while you are resting you may make some quick and sudden movements, but it does not necessarily mean that you are exercising. The fitness watch thinks you are walking or exercising only after the movement lasts for some period. The duration keyword is ideal for situations like this when debouncing is required. The chart Fitness Watcher also tracks the duration of each activity. Under different conditions the chart can send Stateflow® messages to the UI Controller chart, allowing the GUI to display customized notifications.

UI Controller Design

The output data and messages from the Fitness Watcher chart are processed by the UI Controller chart. The chart talks to the GUI by invoking callback functions defined in the App Designer created app. Since these callback functions are defined within the app, they are not immediately known to the Stateflow® chart. The Init state contains scripts enabling Stateflow® to talk to the app. By declaring the app name sf_fitness_app as coder.extrinsic, the Stateflow® model can open the app and store the app handle using a local data app. By declaring the callback functions as coder.extrinsic you can call them anywhere in the same chart. Notice that all callback functions from the app take the local data app as the first argument.

GUI Design With MATLAB® App Designer

The MATLAB® App Designer can be used to quickly lay out the visual components of a user interface through its Design View. It can also be used to program the app behavior via the Code View. In this example, the model created by Simulink® and Stateflow® can co-simulate with the app created by the MATLAB® App Designer. During simulation, you can interact with the GUI. This changes the Simulink® signals which drive the inputs to the Stateflow® charts. For example, when the button Rest on the GUI is pressed, the const block named Activity changes its value to the enum Activity.Rest. Then the Human Simulator starts to produce corresponding signals modeling a resting person. On the other hand, Stateflow® can invoke callback functions defined in the app, which changes the GUI display. For example, if you remain in the Rest state for a given time the Fitness Watcher chart sends out a Stateflow® message to the UI Controller chart, which invokes the callback updateText. A notification then shows up in the main display and replaces the clock for five seconds.

Was this topic helpful?