Quick Start Part 2

Welcome to tutorial 2 of the CertSAFE Quick Start! In this section we will continue with the scenario provided in part 1. It is assumed that you have completed the first part and have the project open in CertSAFE.

To recap, you had received the following requirements for a temperature display system from a customer:


Temperature Display Requirements:

  1. The Temperature Display shall have two temperature sensors, one outside sensor and one inside sensor, which read temperatures in Celsius as 32-bit floating point values.
  2. The display shall sample the sensor data and update every 100 milliseconds.
  3. The temperature °F shall be calculated from the temperature °C with the following equation: °F = °C × 9/5 + 32.
  4. For each sensor the display shall indicate Sensor Broken if the temperature is greater than 150°F or less than -150°F.

In the previous tutorial you modeled requirement #3 as a diagram. Then after modeling, you simulated the diagram to verify that you had correctly implemented the logic.

A good next step would be working on requirement #4. Requirement #4 doesn’t have any direct dependencies on any of the other requirements, but it can easily be linked with requirement #3 to provide a more comprehensive system.

Diagramming the requirement

To begin work on requirement #4 you will want to create a new diagram. This allows you to design and simulate the logic for this requirement separately from the existing diagram for requirement #3. Later on in this tutorial, you will link the two diagrams together to create a subsystem that implements both requirements, using the values computed by one as input for the other.

Looking over requirement #4, you can infer that the input is °F and the output is Sensor Broken. The requirement talks about comparing °F against both 150 and -150, which we can model with two Inline Comparator components. Inline Comparators take in a single numeric value and, based upon their Operator property, performs a comparison between the input value and a predefined constant. Also, since the software must indicate Sensor Broken if either comparison is true, an OR Gate will be needed. An OR Gate takes in two or more Boolean inputs and outputs true if at least one of the inputs is true.

After the Inline Comparators have been added to the diagram, take a second to look at their properties in the Properties View. You will notice that the Inline Comparator’s Operator property is set to “greater than or equal to”. Requirement #4 references a greater than comparison and a less than comparison, not two greater than or equal to comparisons, so you will need to change both of your comparators’ Operator properties to be in line with the requirement. You will also notice that the Inline Comparators have a Value property. Edit these to the appropriate values as specified by the requirement.

Utilizing the skills learned in the previous tutorial, draw a diagram describing requirement #4. When you are finished, you should have a diagram that looks something like the picture below:


Custom components

You now have two diagrams in your CertSAFE project. By changing the root between the two diagrams, you can test each diagram individually, but as the system is now, you can’t simulate the two requirements in tandem. The requirements indicate that the output of requirement #3, °F, serves as the input to requirement #4. As such, you need to connect the two diagrams you have created so that the results from the diagram for requirement #3 are propagated to the diagram for requirement #4.

CertSAFE provides two different features you can use to create a single system containing both diagrams: custom components and stitches. For small systems such as this one, custom components are easy to use and provide a clear high-level visualization of the overall flow of data. However, for larger systems, stitches may be easier to use and can save a lot of time tediously connecting components manually. We will first cover how to join the two diagrams using custom components, then describe how to make an equivalent system using a stitch.

To model the connection between the two subsystems using custom components, first create a new diagram. You then want to add components representing the two existing diagrams into this new diagram. Start by selecting the Temperature Conversion resource in the Projects View and dragging it into the new diagram, as if you were dragging in a standard library component from the Palette view. When you drop the resource into the new diagram, CertSAFE will create a box with the resource’s name in the middle and labeled pins on the sides for the exported names (inputs and outputs) of that resource. The exported names that were determined to be inputs to the resource will be on the left side of the box, and the exported names that were determined to be outputs of the resource will be on the right hand side of the box. See below for what Temperature Conversion looks like as a custom component:

Temperature Conversion as a custom component

Next, drag out the Sensor Check resource into the diagram. You’ll notice that Sensor Check has °F as an input, and Temperature Conversion has °F as an output. You will want to connect a wire network between Temperature Conversion and Sensor Check. Once that is done, add two Exported Names to the diagram, one called °C and connected to the °C input of Temperature Conversion, and the other called Sensor Broken, connected to the Sensor Broken output of Sensor Check.

This is all that really needs to be done to create a diagram connecting the two subsystems. However, it is also sometimes useful to give names to networks in the middle of a diagram that are neither inputs nor outputs of the diagram. Giving a network a name creates a local variable, which allows that network to be added to simulations as a waveform and thereby watched in simulations like an ordinary input or output. Local variable names can be added to a network using the Network Annotation component from the Palette view. The Network Annotation is actually the same component as the Exported Name component, just with the Visibility property set to local instead of exported. (This means you can swap a variable from local to exported at any time just by editing this property.) Local Network Annotation components are drawn as large filled-in dots, as opposed to the hollow diamond or square used for exported Network Annotations.

In this diagram, the only network that does not currently have a name is the one between the two custom components. Add a Network Annotation to this wire network and edit the Network Annotation’s Name property to have a value of °F. When you finish, your diagram should look like this:


A network in a diagram can only be given one name, regardless of whether it is local or exported. If you create several Network Annotation components with the same name in a single diagram, the corresponding networks will be automatically connected as if there was a wire drawn between them. This lets you connect networks far apart in a diagram or break up a complex diagram into smaller chunks. You can do this with exported variables as well as local variables—i.e. you can reference the same input in multiple places in a diagram just by making multiple Exported Name components with the same name.

Making liberal use of clearly-named local variables is very helpful when modeling more complex logic, both for the author and the reader. Beginning modelers tend to underuse local variables and try to draw large diagrams in one monolithic block. If you find yourself fighting with the layout of a complicated diagram, see if breaking it up into smaller pieces using local variables would make the logic easier to understand.


A stitch is similar to a diagram, but instead of having to lay out components on a 2D grid and draw wires to connect them, you can just move items around in a list. Stitches are convenient when you want to connect several subsystems together because CertSAFE will do a lot of the work for you, particularly if the input and output names match up between different definitions.

To create a new stitch, click the New Stitch icon in the toolbar. This will create an empty stitch editor. Looking over the stitch editor, you’ll notice that it has two tables, currently blank. The left table is for composite units (diagrams and other stitches) and the right table is for variables.

To add the two diagrams to your stitch, drag and drop the diagrams from the Projects view to the left table in the stitch editor. When you are finished, the stitch editor should look like this:


Notice that the left pane is shown in a tree-like fashion, with the definition of each composite unit type (diagram or stitch file) you pulled in being the top level nodes, shown with a red background. Right beneath each composite unit type are all the child units of that type, shown with a blue background. Since you only dragged in one copy of each diagram, there will only be a single child unit of each type. Beneath each child unit is the name and appropriate icon for each I/O that child has, shown with a white background.

You will also notice that the right pane has a list of various variable names, their appropriate icons, and their data type. Variables with blue backgrounds that are not indented are stitch variables (analogous to wire networks in a diagram), while variables with white backgrounds that are indented are I/Os associated with child units inside the stitch (analogous to component pins in a diagram). Child unit I/Os are mapped to stitch variables. In this case, the °F I/O in Sensor Check and the °F I/O in Temperature Conversion are mapped to the °F stitch variable. This shows that these two I/Os are connected to each other. As this example demonstrates, one of the nice features of the stitch editor is that I/Os with the same name are automatically connected together by default.

Looking again at the right-hand table, currently all 3 variables have warning/error icons next to them. These problem icons function the same as the colored wire networks in diagrams, with red indicating an error and yellow indicating a warning. In this case, °C has an error because the variable is consumed but not produced; Sensor Broken has a warning because it is produced but not consumed; and °F has a warning because none of the logic is connected to an input or output of the stitch. To correct these problems, you’ll need to tell CertSAFE which variables should be exported from the stitch. Just as with exported variables in diagrams, an exported variable of a stitch acts as an input or output of the stitch that can be connected to external logic.

Looking over the requirements, °C looks to be an input to the system, as it is read in by the sensor hardware directly. Sensor Broken looks to be an output of the system. As these values are either going out of the system, or coming into the system from an outside source, they should be declared as Exported. To explicitly declare a group of stitch variables as Exported, select the variables, then go to the Properties view and set their Visibility property to Exported. When you are finished, the problems should go away, since °C is now a subsystem input that doesn’t need to be produced within the stitch, Sensor Broken is a subsystem output that can be used outside the stitch, and the warning on °F will also go away, since the logic is now connected to I/Os of the stitch. At this point, your stitch should look like this:


Save the stitch into your project as Process All Sensors.

Simulating the system

Once you have saved the stitch, you can simulate the system to check that it matches the requirements. Before simulating the system, it is a good idea to try to come up with a test design that is likely to show if there are any logic issues with the system.

Looking at the requirements, you know Sensor Broken is supposed to be true when °F is less than -150 or greater than 150. So one test that would easily check a lot of cases would be to start with a °C value of -135 and ramp it up to a value of 100. This would correspond to a °F value of -212 and 212, respectively.

Before you can create a simulation for the entire system, you’ll have to specify the root that you are simulating. A root tells CertSAFE what the top-most composite unit in the system you are simulating is. CertSAFE then determines what logic needs to be simulated based upon what is referenced by the root, any of its child units, any of its child units’ child units, etc.

Since you just created the Process All Sensors stitch linking the diagrams for requirements #3 and #4 together, you’ll want to set this stitch as root, allowing both diagrams to be simulated in tandem. Once you have set the root, create a new simulation. (If you have another simulation open when creating a new simulation, and you have the option Root Follows Simulation Editor Focus turned on, then the new simulation will have the same root as the currently opened simulation. To change the root in an already created simulation, either drag the diagram or stitch you would wish to be the root into the simulation, or change the root as specified in the simulation’s properties through the property window. For more information about the Root Follows Simulation Editor Focus option, see the Fast Options Bar documentation.)

Opening up the Instance view, you’ll see the stitch listed as your root, and underneath it will be listed the child units of the stitch and the stitch’s variables.


Select the three stitch variables (Sensor Broken, °C, and °F) and drag them into your simulation. Set each waveform’s Vertical scale and Vertical offset properties to values you find visually pleasing. A waveform’s offset determines where the waveform’s baseline is positioned vertically compared to other waveforms’ baselines. Waveforms with offsets that are numerically close will be placed near each other. A waveform’s scale is a multiplier that determines how much vertical screen space a difference of 1 unit in the value of the variable corresponds to. A waveform scale of 0 will give you a flat line with no vertical variation. A negative scale value will invert the display of the waveform vertically. Waveform scales and offsets have units of pixels, and can be fractional numbers. Waveform scales and offsets do not affect the simulation in any way—they are just there to make organizing and displaying the information in a simulation easier.

Since you want to see what happens when °C starts at -135 and ramps up to 100, put two IntelliPoints on the °C waveform, one at time 0 and one at the last time value. Set the value of the last IntelliPoint to 100. Set the value of the first IntelliPoint to -135, and set its Interpolation base property to linear. Setting the interpolation to linear on the first IntelliPoint makes the value of °C change smoothly from one value to the other. You should see the waveforms for Sensor Broken and °F update to show the new simulated results as you edit the values of the °C input. When finished, your simulation should look similar to this:


To verify that the system does detail the proper logic, simply make sure that all places Sensor Broken is true corresponds to a °F value less than -150 or to a °F value larger than 150, and that all other places Sensor Broken is false. Since °F is a straight line, this can be simplified by looking at the points that Sensor Broken transitions.

This concludes the second quick start tutorial. The third quick start tutorial will show how to finish modeling this set of requirements, including how to reuse logic between redundant subsystems.