| <!DOCTYPE html> |
| <html lang="en"> |
| <head> |
| <meta charset="UTF-8"> |
| <meta http-equiv="X-UA-Compatible" content="IE=edge"> |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> |
| <meta name="generator" content="Asciidoctor 2.0.10"> |
| <meta name="author" content="Copyright (c) 2010, 2020 Contributors to the Eclipse Foundation"> |
| <link rel="icon" type="image/png" href="favicon.png"> |
| <title>CIF documentation (Incubation)</title> |
| <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"> |
| <style> |
| /* Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */ |
| /* Uncomment @import statement to use as custom stylesheet */ |
| /*@import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700";*/ |
| article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section{display:block} |
| audio,video{display:inline-block} |
| audio:not([controls]){display:none;height:0} |
| html{font-family:sans-serif;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%} |
| a{background:none} |
| a:focus{outline:thin dotted} |
| a:active,a:hover{outline:0} |
| h1{font-size:2em;margin:.67em 0} |
| abbr[title]{border-bottom:1px dotted} |
| b,strong{font-weight:bold} |
| dfn{font-style:italic} |
| hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0} |
| mark{background:#ff0;color:#000} |
| code,kbd,pre,samp{font-family:monospace;font-size:1em} |
| pre{white-space:pre-wrap} |
| q{quotes:"\201C" "\201D" "\2018" "\2019"} |
| small{font-size:80%} |
| sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline} |
| sup{top:-.5em} |
| sub{bottom:-.25em} |
| img{border:0} |
| svg:not(:root){overflow:hidden} |
| figure{margin:0} |
| fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em} |
| legend{border:0;padding:0} |
| button,input,select,textarea{font-family:inherit;font-size:100%;margin:0} |
| button,input{line-height:normal} |
| button,select{text-transform:none} |
| button,html input[type="button"],input[type="reset"],input[type="submit"]{-webkit-appearance:button;cursor:pointer} |
| button[disabled],html input[disabled]{cursor:default} |
| input[type="checkbox"],input[type="radio"]{box-sizing:border-box;padding:0} |
| button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0} |
| textarea{overflow:auto;vertical-align:top} |
| table{border-collapse:collapse;border-spacing:0} |
| *,*::before,*::after{-moz-box-sizing:border-box;-webkit-box-sizing:border-box;box-sizing:border-box} |
| html,body{font-size:100%} |
| body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;font-weight:400;font-style:normal;line-height:1;position:relative;cursor:auto;tab-size:4;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased} |
| a:hover{cursor:pointer} |
| img,object,embed{max-width:100%;height:auto} |
| object,embed{height:100%} |
| img{-ms-interpolation-mode:bicubic} |
| .left{float:left!important} |
| .right{float:right!important} |
| .text-left{text-align:left!important} |
| .text-right{text-align:right!important} |
| .text-center{text-align:center!important} |
| .text-justify{text-align:justify!important} |
| .hide{display:none} |
| img,object,svg{display:inline-block;vertical-align:middle} |
| textarea{height:auto;min-height:50px} |
| select{width:100%} |
| .center{margin-left:auto;margin-right:auto} |
| .stretch{width:100%} |
| .subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em} |
| div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0;direction:ltr} |
| a{color:#2156a5;text-decoration:underline;line-height:inherit} |
| a:hover,a:focus{color:#1d4b8f} |
| a img{border:0} |
| p{font-family:inherit;font-weight:400;font-size:1em;line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility} |
| p aside{font-size:.875em;line-height:1.35;font-style:italic} |
| h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em} |
| h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0} |
| h1{font-size:2.125em} |
| h2{font-size:1.6875em} |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em} |
| h4,h5{font-size:1.125em} |
| h6{font-size:1em} |
| hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em;height:0} |
| em,i{font-style:italic;line-height:inherit} |
| strong,b{font-weight:bold;line-height:inherit} |
| small{font-size:60%;line-height:inherit} |
| code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)} |
| ul,ol,dl{font-size:1em;line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit} |
| ul,ol{margin-left:1.5em} |
| ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0;font-size:1em} |
| ul.square li ul,ul.circle li ul,ul.disc li ul{list-style:inherit} |
| ul.square{list-style-type:square} |
| ul.circle{list-style-type:circle} |
| ul.disc{list-style-type:disc} |
| ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0} |
| dl dt{margin-bottom:.3125em;font-weight:bold} |
| dl dd{margin-bottom:1.25em} |
| abbr,acronym{text-transform:uppercase;font-size:90%;color:rgba(0,0,0,.8);border-bottom:1px dotted #ddd;cursor:help} |
| abbr{text-transform:none} |
| blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} |
| blockquote cite{display:block;font-size:.9375em;color:rgba(0,0,0,.6)} |
| blockquote cite::before{content:"\2014 \0020"} |
| blockquote cite a,blockquote cite a:visited{color:rgba(0,0,0,.6)} |
| blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)} |
| @media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2} |
| h1{font-size:2.75em} |
| h2{font-size:2.3125em} |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em} |
| h4{font-size:1.4375em}} |
| table{background:#fff;margin-bottom:1.25em;border:solid 1px #dedede} |
| table thead,table tfoot{background:#f7f8f7} |
| table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left} |
| table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)} |
| table tr.even,table tr.alt{background:#f8f8f7} |
| table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{display:table-cell;line-height:1.6} |
| h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em} |
| h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400} |
| .clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} |
| .clearfix::after,.float-group::after{clear:both} |
| :not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;-webkit-border-radius:4px;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed;word-wrap:break-word} |
| :not(pre)>code.nobreak{word-wrap:normal} |
| :not(pre)>code.nowrap{white-space:nowrap} |
| pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} |
| pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} |
| pre>code{display:block} |
| pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} |
| em em{font-style:normal} |
| strong strong{font-weight:400} |
| .keyseq{color:rgba(51,51,51,.8)} |
| kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;-webkit-border-radius:3px;border-radius:3px;-webkit-box-shadow:0 1px 0 rgba(0,0,0,.2),0 0 0 .1em white inset;box-shadow:0 1px 0 rgba(0,0,0,.2),0 0 0 .1em #fff inset;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap} |
| .keyseq kbd:first-child{margin-left:0} |
| .keyseq kbd:last-child{margin-right:0} |
| .menuseq,.menuref{color:#000} |
| .menuseq b:not(.caret),.menuref{font-weight:inherit} |
| .menuseq{word-spacing:-.02em} |
| .menuseq b.caret{font-size:1.25em;line-height:.8} |
| .menuseq i.caret{font-weight:bold;text-align:center;width:.45em} |
| b.button::before,b.button::after{position:relative;top:-1px;font-weight:400} |
| b.button::before{content:"[";padding:0 3px 0 2px} |
| b.button::after{content:"]";padding:0 2px 0 3px} |
| p a>code:hover{color:rgba(0,0,0,.9)} |
| #header,#content,#footnotes,#footer{width:100%;margin-left:auto;margin-right:auto;margin-top:0;margin-bottom:0;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em} |
| #header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table} |
| #header::after,#content::after,#footnotes::after,#footer::after{clear:both} |
| #content{margin-top:1.25em} |
| #content::before{content:none} |
| #header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0} |
| #header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf} |
| #header>h1:only-child,body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} |
| #header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:-ms-flexbox;display:-webkit-flex;display:flex;-ms-flex-flow:row wrap;-webkit-flex-flow:row wrap;flex-flow:row wrap} |
| #header .details span:first-child{margin-left:-.125em} |
| #header .details span.email a{color:rgba(0,0,0,.85)} |
| #header .details br{display:none} |
| #header .details br+span::before{content:"\00a0\2013\00a0"} |
| #header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)} |
| #header .details br+span#revremark::before{content:"\00a0|\00a0"} |
| #header #revnumber{text-transform:capitalize} |
| #header #revnumber::after{content:"\00a0"} |
| #content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem} |
| #toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em} |
| #toc>ul{margin-left:.125em} |
| #toc ul.sectlevel0>li>a{font-style:italic} |
| #toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0} |
| #toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none} |
| #toc li{line-height:1.3334;margin-top:.3334em} |
| #toc a{text-decoration:none} |
| #toc a:active{text-decoration:underline} |
| #toctitle{color:#7a2518;font-size:1.2em} |
| @media screen and (min-width:768px){#toctitle{font-size:1.375em} |
| body.toc2{padding-left:15em;padding-right:0} |
| #toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto} |
| #toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em} |
| #toc.toc2>ul{font-size:.9em;margin-bottom:0} |
| #toc.toc2 ul ul{margin-left:0;padding-left:1em} |
| #toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em} |
| body.toc2.toc-right{padding-left:0;padding-right:15em} |
| body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}} |
| @media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0} |
| #toc.toc2{width:20em} |
| #toc.toc2 #toctitle{font-size:1.375em} |
| #toc.toc2>ul{font-size:.95em} |
| #toc.toc2 ul ul{padding-left:1.25em} |
| body.toc2.toc-right{padding-left:0;padding-right:20em}} |
| #content #toc{border-style:solid;border-width:1px;border-color:#e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;-webkit-border-radius:4px;border-radius:4px} |
| #content #toc>:first-child{margin-top:0} |
| #content #toc>:last-child{margin-bottom:0} |
| #footer{max-width:100%;background:rgba(0,0,0,.8);padding:1.25em} |
| #footer-text{color:rgba(255,255,255,.8);line-height:1.44} |
| #content{margin-bottom:.625em} |
| .sect1{padding-bottom:.625em} |
| @media screen and (min-width:768px){#content{margin-bottom:1.25em} |
| .sect1{padding-bottom:1.25em}} |
| .sect1:last-child{padding-bottom:0} |
| .sect1+.sect1{border-top:1px solid #e7e7e9} |
| #content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400} |
| #content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em} |
| #content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible} |
| #content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none} |
| #content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221} |
| details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} |
| details>summary:first-of-type{cursor:pointer;display:list-item;outline:none;margin-bottom:.75em} |
| .admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic} |
| table.tableblock.fit-content>caption.title{white-space:nowrap;width:0} |
| .paragraph.lead>p,#preamble>.sectionbody>[class="paragraph"]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)} |
| table.tableblock #preamble>.sectionbody>[class="paragraph"]:first-of-type p{font-size:inherit} |
| .admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%} |
| .admonitionblock>table td.icon{text-align:center;width:80px} |
| .admonitionblock>table td.icon img{max-width:none} |
| .admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase} |
| .admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6)} |
| .admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} |
| .exampleblock>.content{border-style:solid;border-width:1px;border-color:#e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;-webkit-border-radius:4px;border-radius:4px} |
| .exampleblock>.content>:first-child{margin-top:0} |
| .exampleblock>.content>:last-child{margin-bottom:0} |
| .sidebarblock{border-style:solid;border-width:1px;border-color:#dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;-webkit-border-radius:4px;border-radius:4px} |
| .sidebarblock>:first-child{margin-top:0} |
| .sidebarblock>:last-child{margin-bottom:0} |
| .sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} |
| .exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0} |
| .literalblock pre,.listingblock>.content>pre{-webkit-border-radius:4px;border-radius:4px;word-wrap:break-word;overflow-x:auto;padding:1em;font-size:.8125em} |
| @media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} |
| @media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} |
| .literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class="highlight"],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} |
| .literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} |
| .listingblock>.content{position:relative} |
| .listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5} |
| .listingblock:hover code[data-lang]::before{display:block} |
| .listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} |
| .listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} |
| .listingblock pre.highlightjs{padding:0} |
| .listingblock pre.highlightjs>code{padding:1em;-webkit-border-radius:4px;border-radius:4px} |
| .listingblock pre.prettyprint{border-width:0} |
| .prettyprint{background:#f7f7f8} |
| pre.prettyprint .linenums{line-height:1.45;margin-left:2em} |
| pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} |
| pre.prettyprint li code[data-lang]::before{opacity:1} |
| pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} |
| table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} |
| table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} |
| table.linenotable td.code{padding-left:.75em} |
| table.linenotable td.linenos{border-right:1px solid currentColor;opacity:.35;padding-right:.5em} |
| pre.pygments .lineno{border-right:1px solid currentColor;opacity:.35;display:inline-block;margin-right:.75em} |
| pre.pygments .lineno::before{content:"";margin-right:-.125em} |
| .quoteblock{margin:0 1em 1.25em 1.5em;display:table} |
| .quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em} |
| .quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify} |
| .quoteblock blockquote{margin:0;padding:0;border:0} |
| .quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)} |
| .quoteblock blockquote>.paragraph:last-child p{margin-bottom:0} |
| .quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right} |
| .verseblock{margin:0 1em 1.25em} |
| .verseblock pre{font-family:"Open Sans","DejaVu Sans",sans;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility} |
| .verseblock pre strong{font-weight:400} |
| .verseblock .attribution{margin-top:1.25rem;margin-left:.5ex} |
| .quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic} |
| .quoteblock .attribution br,.verseblock .attribution br{display:none} |
| .quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)} |
| .quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none} |
| .quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0} |
| .quoteblock.abstract{margin:0 1em 1.25em;display:block} |
| .quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center} |
| .quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} |
| .quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} |
| .quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem} |
| .quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;text-align:left;margin-right:0} |
| table.tableblock{max-width:100%;border-collapse:separate} |
| p.tableblock:last-child{margin-bottom:0} |
| td.tableblock>.content>:last-child{margin-bottom:-1.25em} |
| td.tableblock>.content>:last-child.sidebarblock{margin-bottom:0} |
| table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} |
| table.grid-all>thead>tr>.tableblock,table.grid-all>tbody>tr>.tableblock{border-width:0 1px 1px 0} |
| table.grid-all>tfoot>tr>.tableblock{border-width:1px 1px 0 0} |
| table.grid-cols>*>tr>.tableblock{border-width:0 1px 0 0} |
| table.grid-rows>thead>tr>.tableblock,table.grid-rows>tbody>tr>.tableblock{border-width:0 0 1px} |
| table.grid-rows>tfoot>tr>.tableblock{border-width:1px 0 0} |
| table.grid-all>*>tr>.tableblock:last-child,table.grid-cols>*>tr>.tableblock:last-child{border-right-width:0} |
| table.grid-all>tbody>tr:last-child>.tableblock,table.grid-all>thead:last-child>tr>.tableblock,table.grid-rows>tbody>tr:last-child>.tableblock,table.grid-rows>thead:last-child>tr>.tableblock{border-bottom-width:0} |
| table.frame-all{border-width:1px} |
| table.frame-sides{border-width:0 1px} |
| table.frame-topbot,table.frame-ends{border-width:1px 0} |
| table.stripes-all tr,table.stripes-odd tr:nth-of-type(odd),table.stripes-even tr:nth-of-type(even),table.stripes-hover tr:hover{background:#f8f8f7} |
| th.halign-left,td.halign-left{text-align:left} |
| th.halign-right,td.halign-right{text-align:right} |
| th.halign-center,td.halign-center{text-align:center} |
| th.valign-top,td.valign-top{vertical-align:top} |
| th.valign-bottom,td.valign-bottom{vertical-align:bottom} |
| th.valign-middle,td.valign-middle{vertical-align:middle} |
| table thead th,table tfoot th{font-weight:bold} |
| tbody tr th{display:table-cell;line-height:1.6;background:#f7f8f7} |
| tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold} |
| p.tableblock>code:only-child{background:none;padding:0} |
| p.tableblock{font-size:1em} |
| ol{margin-left:1.75em} |
| ul li ol{margin-left:1.5em} |
| dl dd{margin-left:1.125em} |
| dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0} |
| ol>li p,ul>li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em} |
| ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none} |
| ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em} |
| ul.unstyled,ol.unstyled{margin-left:0} |
| ul.checklist{margin-left:.625em} |
| ul.checklist li>p:first-child>.fa-square-o:first-child,ul.checklist li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em} |
| ul.checklist li>p:first-child>input[type="checkbox"]:first-child{margin-right:.25em} |
| ul.inline{display:-ms-flexbox;display:-webkit-box;display:flex;-ms-flex-flow:row wrap;-webkit-flex-flow:row wrap;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em} |
| ul.inline>li{margin-left:1.25em} |
| .unstyled dl dt{font-weight:400;font-style:normal} |
| ol.arabic{list-style-type:decimal} |
| ol.decimal{list-style-type:decimal-leading-zero} |
| ol.loweralpha{list-style-type:lower-alpha} |
| ol.upperalpha{list-style-type:upper-alpha} |
| ol.lowerroman{list-style-type:lower-roman} |
| ol.upperroman{list-style-type:upper-roman} |
| ol.lowergreek{list-style-type:lower-greek} |
| .hdlist>table,.colist>table{border:0;background:none} |
| .hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none} |
| td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em} |
| td.hdlist1{font-weight:bold;padding-bottom:1.25em} |
| .literalblock+.colist,.listingblock+.colist{margin-top:-.5em} |
| .colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top} |
| .colist td:not([class]):first-child img{max-width:none} |
| .colist td:not([class]):last-child{padding:.25em 0} |
| .thumb,.th{line-height:0;display:inline-block;border:solid 4px #fff;-webkit-box-shadow:0 0 0 1px #ddd;box-shadow:0 0 0 1px #ddd} |
| .imageblock.left{margin:.25em .625em 1.25em 0} |
| .imageblock.right{margin:.25em 0 1.25em .625em} |
| .imageblock>.title{margin-bottom:0} |
| .imageblock.thumb,.imageblock.th{border-width:6px} |
| .imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em} |
| .image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0} |
| .image.left{margin-right:.625em} |
| .image.right{margin-left:.625em} |
| a.image{text-decoration:none;display:inline-block} |
| a.image object{pointer-events:none} |
| sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super} |
| sup.footnote a,sup.footnoteref a{text-decoration:none} |
| sup.footnote a:active,sup.footnoteref a:active{text-decoration:underline} |
| #footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em} |
| #footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0} |
| #footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em} |
| #footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em} |
| #footnotes .footnote:last-of-type{margin-bottom:0} |
| #content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0} |
| .gist .file-data>table{border:0;background:#fff;width:100%;margin-bottom:0} |
| .gist .file-data>table td.line-data{width:99%} |
| div.unbreakable{page-break-inside:avoid} |
| .big{font-size:larger} |
| .small{font-size:smaller} |
| .underline{text-decoration:underline} |
| .overline{text-decoration:overline} |
| .line-through{text-decoration:line-through} |
| .aqua{color:#00bfbf} |
| .aqua-background{background:#00fafa} |
| .black{color:#000} |
| .black-background{background:#000} |
| .blue{color:#0000bf} |
| .blue-background{background:#0000fa} |
| .fuchsia{color:#bf00bf} |
| .fuchsia-background{background:#fa00fa} |
| .gray{color:#606060} |
| .gray-background{background:#7d7d7d} |
| .green{color:#006000} |
| .green-background{background:#007d00} |
| .lime{color:#00bf00} |
| .lime-background{background:#00fa00} |
| .maroon{color:#600000} |
| .maroon-background{background:#7d0000} |
| .navy{color:#000060} |
| .navy-background{background:#00007d} |
| .olive{color:#606000} |
| .olive-background{background:#7d7d00} |
| .purple{color:#600060} |
| .purple-background{background:#7d007d} |
| .red{color:#bf0000} |
| .red-background{background:#fa0000} |
| .silver{color:#909090} |
| .silver-background{background:#bcbcbc} |
| .teal{color:#006060} |
| .teal-background{background:#007d7d} |
| .white{color:#bfbfbf} |
| .white-background{background:#fafafa} |
| .yellow{color:#bfbf00} |
| .yellow-background{background:#fafa00} |
| span.icon>.fa{cursor:default} |
| a span.icon>.fa{cursor:inherit} |
| .admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default} |
| .admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c} |
| .admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111} |
| .admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900} |
| .admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400} |
| .admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000} |
| .conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);-webkit-border-radius:100px;border-radius:100px;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold} |
| .conum[data-value] *{color:#fff!important} |
| .conum[data-value]+b{display:none} |
| .conum[data-value]::after{content:attr(data-value)} |
| pre .conum[data-value]{position:relative;top:-.125em} |
| b.conum *{color:inherit!important} |
| .conum:not([data-value]):empty{display:none} |
| dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility} |
| h1,h2,p,td.content,span.alt{letter-spacing:-.01em} |
| p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} |
| p,blockquote,dt,td.content,span.alt{font-size:1.0625rem} |
| p{margin-bottom:1.25rem} |
| .sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} |
| .exampleblock>.content{background:#fffef7;border-color:#e0e0dc;-webkit-box-shadow:0 1px 4px #e0e0dc;box-shadow:0 1px 4px #e0e0dc} |
| .print-only{display:none!important} |
| @page{margin:1.25cm .75cm} |
| @media print{*{-webkit-box-shadow:none!important;box-shadow:none!important;text-shadow:none!important} |
| html{font-size:80%} |
| a{color:inherit!important;text-decoration:underline!important} |
| a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important} |
| a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em} |
| abbr[title]::after{content:" (" attr(title) ")"} |
| pre,blockquote,tr,img,object,svg{page-break-inside:avoid} |
| thead{display:table-header-group} |
| svg{max-width:100%} |
| p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3} |
| h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid} |
| #toc,.sidebarblock,.exampleblock>.content{background:none!important} |
| #toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important} |
| body.book #header{text-align:center} |
| body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em} |
| body.book #header .details{border:0!important;display:block;padding:0!important} |
| body.book #header .details span:first-child{margin-left:0!important} |
| body.book #header .details br{display:block} |
| body.book #header .details br+span::before{content:none!important} |
| body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important} |
| body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always} |
| .listingblock code[data-lang]::before{display:block} |
| #footer{padding:0 .9375em} |
| .hide-on-print{display:none!important} |
| .print-only{display:block!important} |
| .hide-for-print{display:none!important} |
| .show-for-print{display:inherit!important}} |
| @media print,amzn-kf8{#header>h1:first-child{margin-top:1.25rem} |
| .sect1{padding:0!important} |
| .sect1+.sect1{border:0} |
| #footer{background:none} |
| #footer-text{color:rgba(0,0,0,.6);font-size:.9em}} |
| @media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}} |
| </style> |
| <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css"> |
| <!-- |
| Copyright (c) 2010, 2020 Contributors to the Eclipse Foundation |
| |
| See the NOTICE file(s) distributed with this work for additional |
| information regarding copyright ownership. |
| |
| This program and the accompanying materials are made available under the terms |
| of the MIT License which is available at https://opensource.org/licenses/MIT |
| |
| SPDX-License-Identifier: MIT |
| --> |
| <style> |
| .menu, .submenu, .menuitem, .menuref { |
| background-color: Menu; |
| } |
| |
| .button { |
| border: 1px solid ButtonFace; |
| /* |
| Styling too similar to a real button is considered bad practice, see https://github.com/asciidoctor/asciidoctor/issues/1881#issuecomment-250702085 |
| border: 2px outset ButtonFace; |
| background-color: ButtonFace; |
| */ |
| padding-left: 0.5ex; |
| padding-right: 0.5ex; |
| font-weight: normal; |
| font-family: "Segoe UI","Open Sans","DejaVu Sans",sans-serif; |
| white-space: nowrap; |
| } |
| .button:before { |
| content: none !important; |
| } |
| .button:after { |
| content: none !important; |
| } |
| |
| #footer-text, #footer-text a { |
| color: rgba(255,255,255,.8) |
| } |
| </style> |
| </head> |
| <body class="book toc2 toc-left"> |
| <div id="header"> |
| <h1>CIF documentation (Incubation)</h1> |
| <div class="details"> |
| <span id="author" class="author">Copyright (c) 2010, 2020 Contributors to the Eclipse Foundation</span><br> |
| <span id="revnumber">version 0.1.0.20210126-175926</span> |
| </div> |
| <div id="toc" class="toc2"> |
| <div id="toctitle">Table of Contents</div> |
| <ul class="sectlevel1"> |
| <li><a href="#introduction-chapter-index">Introduction</a></li> |
| <li><a href="#tut-chapter-index">Language tutorial</a> |
| <ul class="sectlevel2"> |
| <li><a href="#tut-introduction">Introduction</a></li> |
| <li><a href="#tut-lessons">Lessons</a></li> |
| <li><a href="#tut-basics">Basics</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-basics-chapter-automata">Automata</a></li> |
| <li><a href="#tut-basics-chapter-synchronizing-events">Synchronizing events</a></li> |
| <li><a href="#tut-basics-chapter-non-determinism">Non-determinism</a></li> |
| <li><a href="#tut-basics-chapter-alphabet">Alphabet</a></li> |
| <li><a href="#tut-basics-chapter-event-placement">Event declaration placement</a></li> |
| <li><a href="#tut-basics-chapter-shorter-notations">Shorter notations</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-data">Data</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-data-chapter-discrete-variables">Discrete variables</a></li> |
| <li><a href="#tut-data-chapter-discvar-change">Discrete variable value changes</a></li> |
| <li><a href="#tut-data-chapter-loc-var-duality1">Location/variable duality (1/2)</a></li> |
| <li><a href="#tut-data-chapter-loc-var-duality2">Location/variable duality (2/2)</a></li> |
| <li><a href="#tut-data-chapter-read-write">Global read, local write</a></li> |
| <li><a href="#tut-data-chapter-monitoring">Monitoring</a></li> |
| <li><a href="#tut-data-chapter-asgn-old-vs-new">Old and new values in assignments</a></li> |
| <li><a href="#tut-data-chapter-tau-event">The <code>tau</code> event</a></li> |
| <li><a href="#tut-data-chapter-discvar-init">Initial values of discrete variables</a></li> |
| <li><a href="#tut-data-chapter-init-preds">Initialization predicates</a></li> |
| <li><a href="#tut-data-chapter-locs-as-var">Using locations as variables</a></li> |
| <li><a href="#tut-data-chapter-stat-invariants">State (exclusion) invariants</a></li> |
| <li><a href="#tut-data-chapter-stat-evt-excl-invariants">State/event exclusion invariants</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-types-and-values">Types and values</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-values-chapter-types-values-exprs">Types, values, and expressions</a></li> |
| <li><a href="#tut-values-chapter-overview">Values overview</a></li> |
| <li><a href="#tut-values-chapter-integers">Integers</a></li> |
| <li><a href="#tut-values-chapter-integer-ranges">Integer ranges</a></li> |
| <li><a href="#tut-values-chapter-reals">Reals</a></li> |
| <li><a href="#tut-values-chapter-booleans">Booleans</a></li> |
| <li><a href="#tut-values-chapter-strings">Strings</a></li> |
| <li><a href="#tut-values-chapter-enumerations">Enumerations</a></li> |
| <li><a href="#tut-values-chapter-tuples">Tuples</a></li> |
| <li><a href="#tut-values-chapter-lists">Lists</a></li> |
| <li><a href="#tut-values-chapter-bounded-lists-and-arrays">Bounded lists and arrays</a></li> |
| <li><a href="#tut-values-chapter-sets">Sets</a></li> |
| <li><a href="#tut-values-chapter-dictionaries">Dictionaries</a></li> |
| <li><a href="#tut-values-chapter-combining-values">Combining values</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-scalable-solutions-and-reuse-12">Scalable solutions and reuse (1/2)</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-reuse1-chapter-constants">Constants</a></li> |
| <li><a href="#tut-reuse1-chapter-algebraic-variables">Algebraic variables</a></li> |
| <li><a href="#tut-reuse1-chapter-algvar-equations">Algebraic variables and equations</a></li> |
| <li><a href="#tut-reuse1-chapter-type-declarations">Type declarations</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-time">Time</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-time-chapter-intro">Timing</a></li> |
| <li><a href="#tut-time-chapter-continuous-variables">Continuous variables</a></li> |
| <li><a href="#tut-time-chapter-contvar-equations">Continuous variables and equations</a></li> |
| <li><a href="#tut-time-chapter-equations">Equations</a></li> |
| <li><a href="#tut-time-chapter-var-overview">Variables overview</a></li> |
| <li><a href="#tut-time-chapter-urgency">Urgency</a></li> |
| <li><a href="#tut-time-chapter-deadlock-livelock">Deadlock and livelock</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-channel-communication">Channel communication</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-channels-chapter-intro">Channels</a></li> |
| <li><a href="#tut-channels-chapter-void">Dataless channels</a></li> |
| <li><a href="#tut-channels-chapter-chan-sync-combi">Combining channel communication with event synchronization</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-functions">Functions</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-functions-chapter-intro">Functions</a></li> |
| <li><a href="#tut-functions-chapter-internal-functions">Internal user-defined functions</a></li> |
| <li><a href="#tut-functions-chapter-statements">Function statements</a></li> |
| <li><a href="#tut-functions-chapter-functions-as-values">Functions as values</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-scalable-solutions-and-reuse-22">Scalable solutions and reuse (2/2)</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-reuse2-chapter-aut-def-inst">Automaton definition/instantiation</a></li> |
| <li><a href="#tut-reuse2-chapter-aut-def-params">Parametrized automaton definitions</a></li> |
| <li><a href="#tut-reuse2-chapter-aut-def-param-kinds">Automaton definition parameters</a></li> |
| <li><a href="#tut-reuse2-chapter-groups">Groups</a></li> |
| <li><a href="#tut-reuse2-chapter-group-defs">Group definitions</a></li> |
| <li><a href="#tut-reuse2-chapter-imports">Imports</a></li> |
| <li><a href="#tut-reuse2-chapter-imports-libraries">Imports and libraries</a></li> |
| <li><a href="#tut-reuse2-chapter-imports-groups">Imports and groups</a></li> |
| <li><a href="#tut-reuse2-chapter-namespaces">Namespaces</a></li> |
| <li><a href="#tut-reuse2-chapter-input-variables">Input variables</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-stochastics">Stochastics</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-stochastics-chapter-intro">Stochastics</a></li> |
| <li><a href="#tut-stochastics-chapter-discrete-continuous-constant">Discrete, continuous, and constant distributions</a></li> |
| <li><a href="#tut-stochastics-chapter-pseudo-randomness">Pseudo-randomness</a></li> |
| </ul> |
| </li> |
| <li><a href="#tut-language-extensions">Language extensions</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tut-extensions-chapter-synthesis">Supervisory controller synthesis</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li><a href="#lang-ref-chapter-index">Language reference</a> |
| <ul class="sectlevel2"> |
| <li><a href="#lang-ref-syntax-lexical">Lexical syntax</a> |
| <ul class="sectlevel3"> |
| <li><a href="#lang-ref-keywords">Keywords</a></li> |
| <li><a href="#lang-ref-terminals">Terminals</a></li> |
| <li><a href="#lang-ref-whitespace">Whitespace</a></li> |
| <li><a href="#lang-ref-comments">Comments</a></li> |
| </ul> |
| </li> |
| <li><a href="#lang-ref-syntax-grammar">Grammar</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-chapter-index">Tools</a> |
| <ul class="sectlevel2"> |
| <li><a href="#tools-specification-tools">Specification tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-chapter-text-editor">CIF text editor</a></li> |
| <li><a href="#tools-chapter-cif2yed">CIF to yEd transformer</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-supervisory-controller-synthesis-tools">Supervisory controller synthesis tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-chapter-datasynth">Data-based supervisory controller synthesis</a></li> |
| <li><a href="#tools-eventbased-chapter-index">Event-based synthesis toolset</a></li> |
| <li><a href="#tools-chapter-cif2supremica">CIF to Supremica transformer</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-simulation-validation-and-visualization-tools">Simulation, validation, and visualization tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-cifsim-chapter-index">CIF simulator</a></li> |
| <li><a href="#tools-simulation-basics">Simulation basics</a></li> |
| <li><a href="#tools-simulation-inputoutput">Simulation input/Output</a></li> |
| <li><a href="#tools-simulation-advanced-topics">Simulation advanced topics</a></li> |
| <li><a href="#tools-simulation-miscellaneous-topics">Simulation miscellaneous topics</a></li> |
| <li><a href="#tools-simulation-developer-topics">Simulation developer topics</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-verification-tools">Verification tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-chapter-cif2mcrl2">CIF to mCRL2 transformer</a></li> |
| <li><a href="#tools-chapter-cif2uppaal">CIF to UPPAAL transformer</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-real-time-testing-code-generation-and-implementation-tools">Real-time testing, code generation, and implementation tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-codegen-chapter-index">CIF code generator</a></li> |
| <li><a href="#tools-cif2plc-chapter-index">CIF PLC code generator</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-miscellaneous-tools">Miscellaneous tools</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-cif2cif-chapter-index">CIF to CIF transformer</a></li> |
| <li><a href="#tools-chapter-mergecif">CIF merger</a></li> |
| <li><a href="#tools-chapter-event-disabler">CIF event disabler</a></li> |
| <li><a href="#tools-chapter-cif-explorer">CIF explorer</a></li> |
| </ul> |
| </li> |
| <li><a href="#tools-scripting">Scripting</a> |
| <ul class="sectlevel3"> |
| <li><a href="#tools-scripting-chapter-intro">Introduction to scripting</a></li> |
| <li><a href="#tools-scripting-chapter-tools">Overview of scriptable tools</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li><a href="#examples-chapter-index">CIF examples</a></li> |
| <li><a href="#release-notes-chapter-index">CIF release notes</a> |
| <ul class="sectlevel2"> |
| <li><a href="#version-0-1-unreleased">Version 0.1 (unreleased)</a></li> |
| </ul> |
| </li> |
| <li><a href="#dev-chapter-index">Developers</a> |
| <ul class="sectlevel2"> |
| <li><a href="#dev-lang-modify">CIF language modification</a></li> |
| </ul> |
| </li> |
| <li><a href="#legal-chapter-index">Legal</a></li> |
| </ul> |
| </div> |
| </div> |
| <div id="content"> |
| <div id="preamble"> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>CIF is a declarative modeling language for the specification of discrete |
| event, timed, and hybrid systems as a collection of synchronizing automata. |
| The CIF tooling supports the entire development process of controllers, |
| including among others specification, supervisory controller synthesis, |
| simulation-based validation and visualization, verification, real-time |
| testing, and code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>CIF is one of the tools of the |
| <a href="https://eclipse.org/escet">Eclipse ESCET™ project</a>.</p> |
| </div> |
| <div class="admonitionblock warning"> |
| <table> |
| <tr> |
| <td class="icon"> |
| <i class="fa icon-warning" title="Warning"></i> |
| </td> |
| <td class="content"> |
| <div class="paragraph"> |
| <p>The Eclipse ESCET project, including the CIF language and toolset, |
| is currently in the |
| <a href="https://wiki.eclipse.org/Development_Resources/Process_Guidelines/What_is_Incubation">Incubation Phase</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p><span class="image"><img src="./eclipse-incubation.png" alt="eclipse incubation" width="300"></span></p> |
| </div> |
| </td> |
| </tr> |
| </table> |
| </div> |
| <div class="admonitionblock tip"> |
| <table> |
| <tr> |
| <td class="icon"> |
| <i class="fa icon-tip" title="Tip"></i> |
| </td> |
| <td class="content"> |
| You can <a href="eclipse-escet-incubation-cif-manual.pdf">download this manual</a> |
| as a PDF as well. |
| </td> |
| </tr> |
| </table> |
| </div> |
| <div class="paragraph"> |
| <p>The documentation consists of:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#introduction-chapter-index">CIF introduction</a></p> |
| </li> |
| <li> |
| <p><a href="#tut-chapter-index">CIF language tutorial</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-ref-chapter-index">CIF language reference manual</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-index">CIF tool manual</a></p> |
| </li> |
| <li> |
| <p><a href="#examples-chapter-index">CIF examples</a></p> |
| </li> |
| <li> |
| <p><a href="#release-notes-chapter-index">CIF release notes</a></p> |
| </li> |
| <li> |
| <p><a href="#dev-chapter-index">CIF developers manual</a></p> |
| </li> |
| <li> |
| <p><a href="#legal-chapter-index">Legal information</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>A screenshot of the CIF tooling IDE:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./screenshot_ide.png" alt="screenshot ide"> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="introduction-chapter-index">Introduction</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The CIF language is a powerful declarative automata-based modeling language |
| for the specification of discrete event, timed (linear dynamics), hybrid |
| (piecewise continuous dynamics) systems. It can be seen as a rich state |
| machine language with the following main features:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Modular specification with synchronized events and communication between |
| automata.</p> |
| </li> |
| <li> |
| <p>Many data types are available (booleans, integers, reals, tuples, lists, |
| arrays, sets, and dictionaries), combined with a powerful expression language |
| for compact variables updates.</p> |
| </li> |
| <li> |
| <p>Text-based specification of the automata, with many features to simplify |
| modeling large non-trivial industrial systems.</p> |
| </li> |
| <li> |
| <p>Primitives for supervisory controller synthesis are integrated in the |
| language.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF tooling supports the entire development process of controllers, |
| including among others specification, supervisory controller synthesis, |
| simulation-based validation and visualization, verification, real-time |
| testing, and code generation. Highlights of the CIF tooling include:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Text-based editor that allows to easily specify and edit models.</p> |
| </li> |
| <li> |
| <p>Feature-rich powerful data-based synthesis tool. A transformation to the |
| supervisory controller synthesis tool Supremica is also available.</p> |
| </li> |
| <li> |
| <p>A simulator that supports both interactive and automated validation of |
| specifications. Powerful visualization features allow for interactive |
| visualization-based validation.</p> |
| </li> |
| <li> |
| <p>Conversion to formal verification tools such as mCRL2 and UPPAAL.</p> |
| </li> |
| <li> |
| <p>Implementation language code generation (PLC languages, Java, C, and |
| Simulink) for real-time testing and implementation of the designed controller.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="tut-chapter-index">Language tutorial</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>This tutorial introduces the CIF language. It explains the general idea |
| behind the concepts of the language, and shows how to use them, all by means of |
| examples. The tutorial is focused on giving a short introduction to CIF, and |
| does not cover all details. It is recommended reading for all CIF users.</p> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-introduction">Introduction</h3> |
| <div class="paragraph"> |
| <p>CIF stands for <strong>C</strong>ompositional <strong>I</strong>nterchange <strong>F</strong>ormat for hybrid |
| systems. CIF is primarily used to create models of physical systems and their |
| controllers, describing their behavior. However, CIF is a general-purpose |
| modeling language, and can be used to model practically anything, ranging from |
| physical real-world systems to abstract mathematical entities.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p>CIF supports discrete event models, that are mostly concerned with what |
| happens, and in which order. CIF also supports timed systems, where timing |
| plays and explicit role, and hybrid systems, which combine the discrete events |
| with timing. This makes CIF suitable for modeling of all kinds of systems.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF tooling puts a particular focus on supporting the entire development |
| process of controllers. However, just as the CIF language, the CIF tooling can |
| be applied much more generally. The tooling allows among others specification, |
| supervisory controller synthesis, simulation-based validation and |
| visualization, verification, real-time testing, and code generation.</p> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-lessons">Lessons</h3> |
| <div class="paragraph"> |
| <p>Several lessons are available, grouped into the following categories:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-tut-basics">Basics</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-data">Data</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-values">Types and values</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-reuse1">Scalable solutions and reuse (1/2)</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-time">Time</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-channels">Channel communication</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions">Functions</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-reuse2">Scalable solutions and reuse (2/2)</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-stochastics">Stochastics</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-extensions">Language extensions</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The lessons introduce new concepts, one by one, and are meant to be read in |
| the given order.</p> |
| </div> |
| <div id="lang-tut-basics" class="paragraph"> |
| <p><strong>Basics</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-automata">Automata</a></dt> |
| <dd> |
| <p>Explains automata, locations, events, edges, transitions, and more.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-synchronizing-events">Synchronizing events</a></dt> |
| <dd> |
| <p>Explains event synchronization, enabledness, traces, and state spaces.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-non-determinism">Non-determinism</a></dt> |
| <dd> |
| <p>Explains multiple causes of non-determinism.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-alphabet">Alphabet</a></dt> |
| <dd> |
| <p>Explains alphabets for both individual automata and entire specifications.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-event-placement">Event declaration placement</a></dt> |
| <dd> |
| <p>Explains the placement of event declarations.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-basics-chapter-shorter-notations">Shorter notations</a></dt> |
| <dd> |
| <p>Explains several shorter notations, including self loops, declaring |
| multiple events with a single declaration, multiple events on an edge, and |
| nameless locations.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-data" class="paragraph"> |
| <p><strong>Data</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-data-chapter-discrete-variables">Discrete variables</a></dt> |
| <dd> |
| <p>Explains discrete variables, guards, and updates.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-discvar-change">Discrete variable value changes</a></dt> |
| <dd> |
| <p>Explains how and when discrete variables can change value.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-loc-var-duality1">Location/variable duality (1/2)</a></dt> |
| <dd> |
| <p>Explains the duality between locations and variables using a model of a |
| counter.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-loc-var-duality2">Location/variable duality (2/2)</a></dt> |
| <dd> |
| <p>Explains the duality between locations and variables using a model of a |
| lamp.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-read-write">Global read, local write</a></dt> |
| <dd> |
| <p>Explains the concepts of global read and local write.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-monitoring">Monitoring</a></dt> |
| <dd> |
| <p>Explains monitoring, self loops, and monitor automata.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-asgn-old-vs-new">Old and new values in assignments</a></dt> |
| <dd> |
| <p>Explains old and new values of variables in assignments, multiple |
| assignments, and the order of assignments.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-tau-event">The <code>tau</code> event</a></dt> |
| <dd> |
| <p>Explains the <code>tau</code> event.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-discvar-init">Initial values of discrete variables</a></dt> |
| <dd> |
| <p>Explains initialization of discrete variables, including the use of default |
| values and multiple potential initial values.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-init-preds">Initialization predicates</a></dt> |
| <dd> |
| <p>Explains initialization in general, and initialization predicates in |
| particular.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-locs-as-var">Using locations as variables</a></dt> |
| <dd> |
| <p>Explains the use of locations as variables.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-stat-invariants">State (exclusion) invariants</a></dt> |
| <dd> |
| <p>Explains state (exclusion) invariants.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-data-chapter-stat-evt-excl-invariants">State/event exclusion invariants</a></dt> |
| <dd> |
| <p>Explains state/event exclusion invariants.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-values" class="paragraph"> |
| <p><strong>Types and values</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-values-chapter-types-values-exprs">Types, values, and expressions</a></dt> |
| <dd> |
| <p>Explains the concepts of types, values, and expressions, as an introduction |
| for the other lessons in this category.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-overview">Values overview</a></dt> |
| <dd> |
| <p>Provides an overview of the available values, and divides them into |
| categories.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-integers">Integers</a></dt> |
| <dd> |
| <p>Explains integer types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-integer-ranges">Integer ranges</a></dt> |
| <dd> |
| <p>Explains integer ranges.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-reals">Reals</a></dt> |
| <dd> |
| <p>Explains real types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-booleans">Booleans</a></dt> |
| <dd> |
| <p>Explains boolean types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-strings">Strings</a></dt> |
| <dd> |
| <p>Explains string types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-enumerations">Enumerations</a></dt> |
| <dd> |
| <p>Explains enumeration types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-tuples">Tuples</a></dt> |
| <dd> |
| <p>Explains tuple types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-lists">Lists</a></dt> |
| <dd> |
| <p>Explains list types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-bounded-lists-and-arrays">Bounded lists and arrays</a></dt> |
| <dd> |
| <p>Explains bounded lists, arrays, and their relations with regular lists.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-sets">Sets</a></dt> |
| <dd> |
| <p>Explains set types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-dictionaries">Dictionaries</a></dt> |
| <dd> |
| <p>Explains dictionary types, values, and commonly used expressions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-combining-values">Combining values</a></dt> |
| <dd> |
| <p>Explains how to combine values of different types.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-reuse1" class="paragraph"> |
| <p><strong>Scalable solutions and reuse (1/2)</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-reuse1-chapter-constants">Constants</a></dt> |
| <dd> |
| <p>Explains the use of constants.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse1-chapter-algebraic-variables">Algebraic variables</a></dt> |
| <dd> |
| <p>Explains the use of algebraic variables.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse1-chapter-algvar-equations">Algebraic variables and equations</a></dt> |
| <dd> |
| <p>Explains the use of equations to specify values of algebraic variables.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse1-chapter-type-declarations">Type declarations</a></dt> |
| <dd> |
| <p>Explains the use of type declarations.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-time" class="paragraph"> |
| <p><strong>Time</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-time-chapter-intro">Timing</a></dt> |
| <dd> |
| <p>Introduces the concept of timing.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-continuous-variables">Continuous variables</a></dt> |
| <dd> |
| <p>Explains the use of continuous variables.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-contvar-equations">Continuous variables and equations</a></dt> |
| <dd> |
| <p>Explains the use of equations to specify values of continuous variables.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-equations">Equations</a></dt> |
| <dd> |
| <p>Show the use of equations for both continuous and algebraic variables, by |
| means of an example of a |
| <a href="http://en.wikipedia.org/wiki/Nonlinear_system>">non-linear system</a>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-var-overview">Variables overview</a></dt> |
| <dd> |
| <p>Provides an overview of the different kinds of variables in CIF, and their |
| main differences.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-urgency">Urgency</a></dt> |
| <dd> |
| <p>Explains the concept of urgency, as well as the different forms of urgency.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-time-chapter-deadlock-livelock">Deadlock and livelock</a></dt> |
| <dd> |
| <p>Explains the concepts of deadlock and livelock.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-channels" class="paragraph"> |
| <p><strong>Channel communication</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-channels-chapter-intro">Channels</a></dt> |
| <dd> |
| <p>Explains point-to-point channels and data communication.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-channels-chapter-void">Dataless channels</a></dt> |
| <dd> |
| <p>Explains <code>void</code> channels that do not communicate any data.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-channels-chapter-chan-sync-combi">Combining channel communication with event synchronization</a></dt> |
| <dd> |
| <p>Explains how channel communication can be combined with event |
| synchronization, further restricting the communication.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-functions" class="paragraph"> |
| <p><strong>Functions</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-functions-chapter-intro">Functions</a></dt> |
| <dd> |
| <p>Introduces functions, and explains the different kind of functions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-functions-chapter-internal-functions">Internal user-defined functions</a></dt> |
| <dd> |
| <p>Explains internal user-defined functions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-functions-chapter-statements">Function statements</a></dt> |
| <dd> |
| <p>Explains the different statements that can be used in internal user-defined |
| functions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-functions-chapter-functions-as-values">Functions as values</a></dt> |
| <dd> |
| <p>Explains using functions as values, allowing functions to be passed around.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-reuse2" class="paragraph"> |
| <p><strong>Scalable solutions and reuse (2/2)</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-aut-def-inst">Automaton definition/instantiation</a></dt> |
| <dd> |
| <p>Explains using automaton definition and instantiation for reuse.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-aut-def-params">Parametrized automaton definitions</a></dt> |
| <dd> |
| <p>Explains parametrized automaton definitions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-aut-def-param-kinds">Automaton definition parameters</a></dt> |
| <dd> |
| <p>Explains the different kinds of parameters of automaton definitions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-groups">Groups</a></dt> |
| <dd> |
| <p>Explains hierarchical structuring using groups.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-group-defs">Group definitions</a></dt> |
| <dd> |
| <p>Explains groups definitions and parametrized group definitions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-imports">Imports</a></dt> |
| <dd> |
| <p>Explains splitting CIF specifications over multiple files using imports.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-imports-libraries">Imports and libraries</a></dt> |
| <dd> |
| <p>Explains how to create libraries that can be used by multiple CIF |
| specifications using imports, as well as how to use imports to include |
| CIF specifications from other directories.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-imports-groups">Imports and groups</a></dt> |
| <dd> |
| <p>Explains how imports and groups interact.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-namespaces">Namespaces</a></dt> |
| <dd> |
| <p>Explains namespaces, and how they can be used together with imports.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-reuse2-chapter-input-variables">Input variables</a></dt> |
| <dd> |
| <p>Explains input variables, how they can be used for coupling with other |
| models and systems, and their relation to imports.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-stochastics" class="paragraph"> |
| <p><strong>Stochastics</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-stochastics-chapter-intro">Stochastics</a></dt> |
| <dd> |
| <p>Introduction to stochastic distributions, which allow for sampling, making |
| it possible to produce random values.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-stochastics-chapter-discrete-continuous-constant">Discrete, continuous, and constant distributions</a></dt> |
| <dd> |
| <p>Explains the different categories of stochastic distributions: discrete, |
| continuous, and constant distributions.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-stochastics-chapter-pseudo-randomness">Pseudo-randomness</a></dt> |
| <dd> |
| <p>Explains how computers implement stochastics using pseudo-random number |
| generators, and how this affects the use of stochastics in CIF.</p> |
| </dd> |
| </dl> |
| </div> |
| <div id="lang-tut-extensions" class="paragraph"> |
| <p><strong>Language extensions</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-extensions-chapter-synthesis">Supervisory controller synthesis</a></dt> |
| <dd> |
| <p>Explains how to extend a model to make it suitable for supervisory |
| controller synthesis.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tools-cifsim-output-print-chapter-index">Print output</a></dt> |
| <dd> |
| <p>Explains how to extend a model to include printing of textual output.</p> |
| <div class="paragraph"> |
| <p>This documentation is currently not part of the language tutorial, |
| but of the simulator tool documentation.</p> |
| </div> |
| </dd> |
| <dt class="hdlist1"><a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualization</a></dt> |
| <dd> |
| <p>Explains how to extend a model to couple it to an image for visualization.</p> |
| <div class="paragraph"> |
| <p>This documentation is currently not part of the language tutorial, |
| but of the simulator tool documentation.</p> |
| </div> |
| </dd> |
| <dt class="hdlist1"><a href="#tools-cifsim-input-svg-chapter-index">SVG interaction</a></dt> |
| <dd> |
| <p>Explains how to extend a model to couple it to an image for interaction via |
| a visualization.</p> |
| <div class="paragraph"> |
| <p>This documentation is currently not part of the language tutorial, |
| but of the simulator tool documentation.</p> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-basics">Basics</h3> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-automata">Automata</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p>CIF models consist of <em>components</em>. Each of the components represents the |
| behavior of a part of the system. Components can be modeled as <em>automata</em>, |
| which form the basis of CIF. The following CIF <em>specification</em>, or CIF <em>model</em>, |
| shows a simple automaton:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp: |
| event turn_on, turn_off; |
| |
| location on: |
| initial; |
| edge turn_off goto off; |
| |
| location off: |
| edge turn_on goto on; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The automaton is named <code>lamp</code>, and not surprisingly represents the (discrete) |
| behavior of a lamp.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="lang-tut-basics-automata-events" class="paragraph"> |
| <p>Automaton <code>lamp</code> declares two <em>events</em>, named <code>turn_on</code> and <code>turn_off</code>. |
| Events model things that can happen in a system. They represent changes. For |
| instance, the <code>turn_on</code> event indicates that the lamp is being turned on. It |
| represents the change from the lamp being off to the lamp being on. The event |
| declaration in the <code>lamp</code> automaton declares two events. The event |
| declaration only indicates that these events exist, it does not yet indicate |
| when they can happen, and what the result of them happening is.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="lang-tut-basics-automata-location" class="paragraph"> |
| <p>All automata have one or more <em>locations</em>, which represent the mutually |
| exclusive <em>states</em> of the automaton. The <code>lamp</code> automaton has two |
| <em>locations</em>, named <code>on</code> and <code>off</code>. Automata have an <em>active</em> or <em>current</em> |
| location. That is, for every automaton one of its location is the active |
| location, and the automaton is said to be <em>in</em> that location. For instance, |
| the <code>lamp</code> automaton is either in its <code>on</code> location, or in its <code>off</code> |
| location.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-basics-automata-loc-init" class="paragraph"> |
| <p>Initially, the lamp is on, as indicated by the <code>initial</code> keyword in the |
| <code>on</code> location. That is, the <code>on</code> location is the initial location of the |
| <code>lamp</code> automaton. The initial location is the active location of the |
| automaton, at the start of the system.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-basics-edge" class="paragraph"> |
| <p>In each location, an automaton can have different behavior, specified using |
| <em>edges</em>. An edge indicates how an automaton can change its state, by going from |
| one location to another. Edges can be associated with events, that indicate |
| what happened, and thus what caused the state change.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>lamp</code> automaton has an edge with the <code>turn_off</code> event, in its <code>on</code> |
| location, going to the <code>off</code> location. Whenever the lamp is on, the <code>lamp</code> |
| automaton is in its <code>on</code> location. Whenever the lamp is turned off, the |
| <code>turn_off</code> event happens. The edge with that event indicates what the |
| result of that event is, for the <code>on</code> location. In this case the result is |
| that the lamp will then be off, which is why the edge goes to the <code>off</code> |
| location.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="lang-tut-basics-trans" class="paragraph"> |
| <p>The <code>lamp</code> automaton can go from one location to another, as described by its |
| edges. This is referred to as 'performing a transition', 'taking a transition', |
| or 'taking an edge'. The <code>lamp</code> automaton can keep performing <em>transitions</em>. |
| The lamp can be turned on, off, on again, off again, etc. This can go on |
| forever.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-synchronizing-events">Synchronizing events</h4> |
| <div class="paragraph"> |
| <p> |
| The power of events is that they synchronize. To illustrate this, consider |
| the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer: |
| event produce, provide; |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The automaton represents a producer that produces products, to be consumed |
| by a consumer. The <code>producer</code> automaton starts in its <code>producing</code> location, |
| in which it produces a product. Once the product has been produced, indicated |
| by the <code>produce</code> event, the automaton will be in its <code>idle</code> location, where |
| it waits until it can <code>provide</code> the produced product to the consumer. Once it |
| has provided the product to the consumer, it will once again be <code>producing</code> |
| another product. Consider also the following continuation of the above |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton consumer: |
| event consume; |
| |
| location idle: |
| initial; |
| edge producer.provide goto consuming; |
| |
| location consuming: |
| edge consume goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This second automaton represents a consumer that consumes products. The |
| <code>consumer</code> is initially <code>idle</code>, waiting for a product from the producer. |
| Once the producer has provided a product, the consumer will be <code>consuming</code>. |
| Once it has consumed the product, as indicated by the occurrence of the |
| <code>consume</code> event, it will become <code>idle</code> again.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The specification has three events, the <code>produce</code> and <code>provide</code> events |
| declared in the <code>producer</code> automaton, and the <code>consume</code> event declared in |
| the <code>consumer</code> automaton. The <code>consumer</code> automaton, in its <code>idle</code> |
| location, has an edge that refers to the <code>provide</code> event declared in the |
| <code>producer</code> automaton. As such, that edge and the edge in the <code>idle</code> |
| location of the <code>producer</code> automaton, refer to the same event.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-synchronization">Synchronization</h5> |
| <div class="paragraph"> |
| <p>Events that are used in multiple automata, must <em>synchronize</em>. That is, if |
| one of those automata performs a transition for that event, the other automata |
| must also participate by performing a transition for that same event. If one |
| of the automata that uses the event can not perform a transition in its current |
| location, none of the automata can perform a transition for that event.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Now, lets take a closer look at the behavior of the producer/consumer example. |
| Initially, the <code>producer</code> automaton is in its <code>producing</code> location, and the |
| <code>consumer</code> automaton is in its <code>idle</code> location. Since the <code>producer</code> is |
| the only automaton that uses the <code>produce</code> event, and there is an (outgoing) |
| edge in its current location for that <code>produce</code> event, the <code>producer</code> can |
| go to its <code>idle</code> location by means of that event.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both the <code>producer</code> and <code>consumer</code> use the <code>provide</code> event. The |
| <code>producer</code> has no edge with that event in its <code>producing</code> location, while |
| the <code>consumer</code> does have an edge for that event in its <code>idle</code> location. |
| Since events must synchronize, and the <code>producer</code> can not participate, the |
| event can not occur at this time. This is what we expect, as the <code>producer</code> |
| has not yet produced a product, and can thus not yet <code>provide</code> it to the |
| consumer. The <code>consumer</code> will have to remain <code>idle</code> until the <code>producer</code> |
| has produced a product and is ready to <code>provide</code> it to the <code>consumer</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The <code>producer</code> blocks the <code>provide</code> event in this case, and is said to |
| <em>disable</em> the event. The event is not blocked by the <code>consumer</code>, and is thus |
| said to be <em>enabled</em> in the <code>consumer</code> automaton. In the entire |
| specification, the event is <em>disabled</em> as well, as it is disabled by at least |
| one of the automata of the specification, and all automata must enable the |
| event for it to become enabled in the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The only behavior that is possible, is for the <code>producer</code> to <code>produce</code> a |
| product, and go to its <code>idle</code> location. The <code>consumer</code> does not participate |
| and remains in its <code>idle</code> location. Both automata are then in their <code>idle</code> |
| location, and both have an edge that enables the <code>provide</code> event. As such, |
| the <code>provide</code> event is enabled in the specification. As this is the only |
| possible behavior, a transition for the <code>provide</code> event is performed. This |
| results in the <code>producer</code> going back to its <code>producing</code> location, while at |
| the same time the <code>consumer</code> goes to its <code>consuming</code> location.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In its <code>producing</code> location, the <code>producer</code> can <code>produce</code> a product. |
| Furthermore, in its <code>consuming</code> location, the <code>consumer</code> can <code>consume</code> a |
| product. Two transitions are possible, and CIF does not define which one will |
| be performed. That is, either one can be performed. No assumptions should be |
| made either way. In other words, both transitions represent valid behavior, as |
| described by this specification. Since only one transition can be taken at a |
| time, there are two possibilities. Either the <code>producer</code> starts to |
| <code>produce</code> the product first, and the <code>consumer</code> starts to <code>consume</code> after |
| that, or the other way around.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-traces-and-state-spaces">Traces and state spaces</h5> |
| <div class="paragraph"> |
| <p>Once both transitions have been taken, we are essentially in the same situation |
| as we were after the <code>producer</code> produced a product the first time, as both |
| automata will be in their <code>idle</code> locations again. The behavior of the |
| specification then continues to repeat forever. However, for each repetition |
| different choices in the order of production and consumption can be made.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| During a single <em>execution</em> or <em>simulation</em>, choices are made each time that |
| multiple transitions are possible. The sequence of transitions that are taken |
| is called a <em>trace</em>. Examples of traces for the producer/consumer example are:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>produce</code> → |
| <code>provide</code> → |
| <code>produce</code> → |
| <code>consume</code> → |
| <code>provide</code> → |
| <code>produce</code> → |
| <code>consume</code> → |
| …​</p> |
| </li> |
| <li> |
| <p><code>produce</code> → |
| <code>provide</code> → |
| <code>produce</code> → |
| <code>consume</code> → |
| <code>provide</code> → |
| <code>consume</code> → |
| <code>produce</code> → |
| …​</p> |
| </li> |
| <li> |
| <p><code>produce</code> → |
| <code>provide</code> → |
| <code>consume</code> → |
| <code>produce</code> → |
| <code>provide</code> → |
| <code>produce</code> → |
| <code>consume</code> → |
| …​</p> |
| </li> |
| <li> |
| <p><code>produce</code> → |
| <code>provide</code> → |
| <code>consume</code> → |
| <code>produce</code> → |
| <code>provide</code> → |
| <code>consume</code> → |
| <code>produce</code> → |
| …​</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The traces end with <code>...</code> to indicate that they are partial traces, that go |
| beyond the part of the trace that is shown. These four traces however, cover |
| all the possibilities for the first seven transitions.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| All possible traces together form the <em>state space</em>, which represents all the |
| possible behavior of a system. For the producer/consumer example, the state |
| space is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/basics/producer_consumer_state_space_finite.png" alt="producer consumer state space finite"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here the circles represent the states of the specification, which are a |
| combination of the states of the two automata. The labels of the circles |
| indicate the state, as a combination of the first letters of the locations of |
| the automata. The initial state is labeled <code>p/i</code>, as initially automaton |
| <code>producer</code> is in its <code>producing</code> (p) location, and the <code>consumer</code> is in |
| its <code>idle</code> (i) location. The arrows indicate the transitions, and are labeled |
| with events. The state space clearly shows the choices, as multiple outgoing |
| arrows for a single state. It also makes it clear that as we move to the right, |
| and make choices, we can make different choices for different products. |
| Since the behavior keeps repeating itself, the state space ends with <code>...</code> |
| to indicate that only a part of the state space is shown.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, we can also show the entire behavior of the specification. Essential |
| here is that the state space shown above has duplicate states. That is, several |
| states have the same label, and allow for the same future behavior. By reusing |
| states, a finite representation of the state space can be made, which shows the |
| entire possible infinite behavior of the producer/consumer specification:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/basics/producer_consumer_state_space_infinite.png" alt="producer consumer state space infinite"> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-concluding-remarks">Concluding remarks</h5> |
| <div class="paragraph"> |
| <p>By using multiple automata, the producer and consumer were modeled |
| independently, allowing for separation of concerns. This is an important |
| concept, especially when modeling larger systems. In general, the large system |
| is decomposed into parts, usually corresponding to physical entities. Each of |
| the parts of the system can then be modeled in isolation, with little regard |
| for the other parts.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By using synchronizing events, the different automata that model different |
| parts of a system, can interact. This allows for modeling of the connection |
| between the different parts of the system, ensuring that together they |
| represent the behavior of the entire system.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-non-determinism">Non-determinism</h4> |
| <div class="paragraph"> |
| <p> |
| Depending on the context in which it is used, non-determinism can mean |
| different things. One definition is having multiple possible traces through the |
| state space of a system. Another definition is having multiple possible |
| transitions for a certain event, for a certain state. Different communities |
| also use different definitions, and some communities only use one of the |
| definitions, and use a different name to refer to the other concept.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-non-determinism-between-events">Non-determinism between events</h5> |
| <div class="paragraph"> |
| <p>One cause of non-determinism is that multiple events are enabled, leading to |
| multiple possible transitions. In other words, there are multiple possible |
| traces through the state space. During the lesson on |
| <a href="#tut-basics-chapter-synchronizing-events">synchronizing events</a>, we already |
| encountered this form of non-determinism, as transitions for the <code>produce</code> and |
| <code>consume</code> events could be performed in arbitrary order.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-non-determinism-for-single-event">Non-determinism for single event</h5> |
| <div class="paragraph"> |
| <p>Another cause of non-determinism is the presence of multiple outgoing edges of |
| a single location for the same event. This can lead to multiple possible |
| transitions for a that event, for a single state. For instance, consider the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton coin: |
| event toss, land, pick_up; |
| |
| location hand: |
| initial; |
| edge toss goto air; |
| |
| location air: |
| edge land goto ground; |
| |
| location ground: |
| edge pick_up goto hand; |
| end |
| |
| automaton outcome: |
| location unknown: |
| initial; |
| edge coin.land goto heads; // First way to land. |
| edge coin.land goto tails; // Second way to land. |
| |
| location heads: |
| edge pick_up goto unknown; |
| |
| location tails: |
| edge pick_up goto unknown; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>coin</code> automaton represents a single coin. Initially, it is in the |
| <code>hand</code> of a person. That person can <code>toss</code> the coin up into the <code>air</code>, |
| eventually causing it to fall and <code>land</code> on the <code>ground</code>. It can be picked |
| up (event <code>pick_up</code>), causing it to once again be in the <code>hand</code> of a |
| person.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>outcome</code> automaton registers the outcome of the |
| <a href="http://en.wikipedia.org/wiki/Coin_toss">coin toss</a>. Initially, |
| the outcome is <code>unknown</code>. Whenever the coin is tossed, it lands (event |
| <code>land</code> from automaton <code>coin</code>) on the ground with either the <code>heads</code> or |
| <code>tails</code> side up. The <code>unknown</code> location of the <code>outcome</code> automaton has |
| two edges for the same event. This leads to two possible transitions, one to |
| the <code>heads</code> location, and one to the <code>tails</code> location. This is a |
| non-deterministic choice, as the model does not specify which transition is |
| chosen, or even which choice is more likely.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In both the <code>heads</code> and <code>tails</code> locations, the coin can be picked up again, |
| making the outcome <code>unknown</code>. The coin can be tossed again and again, |
| repeating the behavior forever. The following figure shows the state space of |
| this specification:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/basics/coin_toss_state_space.png" alt="coin toss state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the first letters of the current locations of the |
| two automata.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-alphabet">Alphabet</h4> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p>The lesson on <a href="#tut-basics-chapter-synchronizing-events">synchronizing events</a> |
| described how events that are used in multiple automata exhibit synchronizing |
| behavior. That is, if the event is used in multiple automata, they must all |
| enable that event in order for a transition to be possible. If one of them can |
| not perform the event, the event is disabled, and none of the automata can |
| perform a transition for that event.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Whether an automaton participates in the synchronization for a certain event, |
| is determined by its <em>alphabet</em>. The alphabet of an automaton is the collection |
| of events over which it synchronizes.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-default-and-implicit-alphabets">Default and implicit alphabets</h5> |
| <div class="paragraph"> |
| <p>By default, the alphabet of an automaton implicitly contains all the events |
| that occur on the edges of the automaton. For instance, consider the following |
| CIF specification (the producer/consumer example from the lesson on |
| <a href="#tut-basics-chapter-synchronizing-events">synchronizing events</a>):</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer: |
| event produce, provide; |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end |
| |
| automaton consumer: |
| event consume; |
| |
| location idle: |
| initial; |
| edge producer.provide goto consuming; |
| |
| location consuming: |
| edge consume goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The alphabet of the <code>producer</code> automaton contains the events <code>produce</code> and |
| <code>provide</code>, as both occur on edges of that automaton. The alphabet of the |
| <code>consumer</code> automaton contains the events <code>producer.produce</code> and |
| <code>consume</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-basics-alphabet-explicit">Explicit alphabet</h5> |
| <div class="paragraph"> |
| <p>It is possible to explicitly specify the alphabet of an automaton, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event provide; |
| |
| automaton producer: |
| event produce; |
| |
| alphabet produce, provide; // Alphabet explicitly specified. |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>alphabet</code> keyword is followed by the events that comprise the alphabet |
| of the automaton, separated by commas. In this case, the alphabet contains |
| the <code>produce</code> and <code>provide</code> events. Since this explicitly specified |
| alphabet is exactly the same as the default alphabet, it could just as easily |
| be omitted.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-non-default-alphabet">Non-default alphabet</h5> |
| <div class="paragraph"> |
| <p>The alphabet is allowed to be empty, which can be explicitly specified as |
| follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alphabet; // Empty alphabet. Automaton doesn't synchronize over any events.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| However, the alphabet of an automaton must at least contain the events that |
| occur on the edges of an automaton. That is, it must at least contain the |
| default alphabet.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| It may however also contain additional events. Since there are no edges for |
| those additional events, the automaton can never enable those events, and |
| thus always disables them. If a single automaton disables an event, and since |
| it must always participate if it has that event in its alphabet, this means |
| that the event becomes globally disabled in the entire specification. Having |
| such additional events in the alphabet leads to a warning, to inform about the |
| potential undesired effects of globally disabling events in this manner.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-implicit-vs-explicit">Implicit vs explicit</h5> |
| <div class="paragraph"> |
| <p>It should be clear that for most automata, the implicit default alphabet |
| suffices. There are however reasons for explicitly specifying the default |
| alphabet. For large automata, it can improve the readability, as the explicit |
| alphabet makes it easy to determine the alphabet of the automaton, without |
| having to look at all the edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The need to explicitly specifying a non-default alphabet rarely occurs. |
| However, several <a href="#tools-chapter-index">tools</a> generate CIF specifications with |
| explicit alphabets.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-event-placement">Event declaration placement</h4> |
| <div class="paragraph"> |
| <p> |
| Consider the following CIF specification (the producer/consumer example from |
| the lesson on <a href="#tut-basics-chapter-synchronizing-events">synchronizing events</a>):</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer: |
| event produce, provide; |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end |
| |
| automaton consumer: |
| event consume; |
| |
| location idle: |
| initial; |
| edge producer.provide goto consuming; |
| |
| location consuming: |
| edge consume goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The specification could also be specified as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer: |
| event produce, provide, consume; // Declaration of event 'consume' moved. |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end |
| |
| automaton consumer: |
| location idle: |
| initial; |
| edge producer.provide goto consuming; |
| |
| location consuming: |
| edge producer.consume goto idle; // Event 'consume' from 'producer'. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>consume</code> event is now declared in the <code>producer</code> automaton rather than |
| the <code>consumer</code> automaton, but the locations and edges have not changed. This |
| modified specification exhibits the same behavior as the original.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It should be clear that while events can be declared in various places, it is |
| best to declare them where they belong. That is, the <code>consume</code> event is only |
| used by the <code>consumer</code> automaton, and is thus best declared in that |
| automaton. Similarly, the <code>produce</code> event is only used by the <code>producer</code> |
| automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>provide</code> event however is used by both automata. In such cases the event |
| is usually declared where it is initiated. In the example above, the producer |
| provides the product to the consumer, and not the other way around. Therefore, |
| the <code>provide</code> event is declared in the <code>producer</code> automaton, rather than in |
| the <code>consumer</code> automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, the modeler is free to choose the best place to declare the event. If |
| no choice can be made between the automata, the event can also be declared |
| outside the automata, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event provide; // Event 'provide' now declared outside the automata. |
| |
| automaton producer: |
| event produce; |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide goto producing; |
| end |
| |
| automaton consumer: |
| event consume; |
| |
| location idle: |
| initial; |
| edge provide goto consuming; // Can directly refer to 'provide' event. |
| |
| location consuming: |
| edge consume goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification also has the same behavior. Only the placement of the event |
| declarations has changed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The place where an event is declared is of no influence to the |
| implicit (default) <a href="#tut-basics-chapter-alphabet">alphabets</a> of the |
| automata. The implicit alphabet of an automaton is determined solely based on |
| the events that occur on the edges of that automaton.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-basics-chapter-shorter-notations">Shorter notations</h4> |
| <div class="paragraph"> |
| <p>This lessons explains several short notations, that can be used for easier |
| modeling, can reduce the size of the specification, and make specifications |
| easier to read. The following topics are discussed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-tut-basics-shorter-notations-self-loop">Self loop</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-basics-shorter-notations-evt-decl-mult">Declaring multiple events with a single declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-basics-shorter-notations-edge-mult-evt">Multiple events on an edge</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-basics-shorter-notations-loc-nameless">Nameless location</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-basics-shorter-notations-self-loop">Self loop</h5> |
| <div class="paragraph"> |
| <p>A self loop is an edge that goes to the location from which it originated. |
| Consider the following example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| event e; |
| |
| location x: |
| edge e goto x; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The edge in location <code>x</code> of automaton <code>a</code> goes to location <code>x</code>. The |
| effect of the <code>e</code> event is that automaton <code>a</code> remains in its <code>x</code> |
| location. A self loop can be used to allow a certain event, essentially |
| ignoring it for that location.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following short notation can be used for self loops:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| event e; |
| |
| location x: |
| edge e; // Goto omitted for self loop. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>goto</code> part of the edge can be omitted for self loop. This can help make |
| the model easier to read, as the resulting location does not have to be checked |
| against the source location of the edge, to see whether they match.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-basics-shorter-notations-evt-decl-mult">Declaring multiple events with a single declaration</h5> |
| <div class="paragraph"> |
| <p>Several of the previous lessons already showed that multiple events can be |
| declared using a single event declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event a, b, c; // Single declaration declares multiple events.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is equivalent to using multiple event declarations that each declare a |
| single event:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event a; // Multiple declarations each declare a single event. |
| event b; |
| event c;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Using a single declaration to declare multiple events can help reduce the |
| length of a specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-basics-shorter-notations-edge-mult-evt">Multiple events on an edge</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| event e, f; |
| |
| location loc: |
| edge e goto loc; // Two edges that only differ in the event. |
| edge f goto loc; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This can also be written more compactly, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| event e, f; |
| |
| location loc: |
| edge e, f goto loc; // Edge with two events. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>An edge with two or more events means exactly the same as having individual |
| edges for the different events. That is, a choice is made between them. It does |
| <em>not</em> specify that event <code>f</code> can only happen after event <code>e</code> has already |
| happened. Both automata thus have the exact same behavior.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-basics-shorter-notations-loc-nameless">Nameless location</h5> |
| <div class="paragraph"> |
| <p>Several of the examples above show automata with a single location. For such |
| automata, the name of the location is optional:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| event e; |
| |
| location: |
| edge e; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Since the location has no name, there is no way to refer to it in a <code>goto</code>, |
| and thus only self loop edges can be used. Leaving out the name prevents having |
| to come up with a dummy name, which can clutter the specification.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-data">Data</h3> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-discrete-variables">Discrete variables</h4> |
| <div class="paragraph"> |
| <p>This lesson introduces discrete variables. Consider the following |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment, decrement; |
| |
| disc int count = 3; |
| |
| location: |
| edge decrement when count > 0 do count := count - 1; |
| edge increment when count < 5 do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The <code>counter</code> automaton can be used to count certain things. The |
| <code>increment</code> and <code>decrement</code> events are used to change the count. The count |
| itself is stored in a variable named <code>count</code>. CIF has several different types |
| of variables. Here, we use a discrete variable, as indicated by the <code>disc</code> |
| keyword. The variable has an <code>int</code> data type, meaning it can have integer |
| numbers as its value. It is initialized to value <code>3</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The automaton has two edges, one for the <code>increment</code> event, and one for the |
| <code>decrement</code> event. The edge for the <code>decrement</code> event has a <em>guard</em> that |
| indicates under which circumstances the event can take place. The condition is |
| indicated using the <code>when</code> keyword. In this case, the guard ensures that the |
| count can only be decremented if it is currently positive. The guard of the |
| edge for the <code>increment</code> event indicates that the count can only be |
| incremented as long as it is less than five. In general, a guard must hold in |
| the source location of the edge, for the edge to be enabled, and a transition |
| to be possible. If the guard is not specified, it defaults to <code>true</code>, which |
| always holds and does not restrict the edge in any way.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| Both edges also have <em>updates</em>, indicated using the <code>do</code> keyword. Updates can |
| be used to specify the effect of the transition on variables. In this case, the |
| updates <em>assign</em> a new value to the <code>count</code> variable that is one less or one |
| more than the current value. That is the value of the <code>count</code> variable is |
| decremented or incremented by one.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This specification represents a counter that can be repeatedly incremented and |
| decremented by one, and ensures that the value of variable <code>count</code> is always |
| at least zero and at most five.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state space of the <code>counter</code> automaton is as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/counter_state_space.png" alt="counter state space"> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-discvar-change">Discrete variable value changes</h4> |
| <div class="paragraph"> |
| <p> |
| Discrete variables can only change value by explicitly assigning them a new |
| value in the <code>do</code> part of an edge. If an edge does not assign a value to a |
| discrete variable, that variable keeps its current value. Consider the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp: |
| event turn_on, turn_off; |
| |
| disc int count = 0; |
| |
| location off: |
| initial; |
| edge turn_on do count := count + 1 goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is the same <code>lamp</code> automaton as used in the lesson on |
| <a href="#tut-basics-chapter-automata">automata</a>, but with a <code>count</code> variable added. This |
| variable is used to count the number of times that the lamp has been turned on. |
| The edge for the <code>turn_on</code> event increments the value of the variable by one, |
| each time the lamp is turned on.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The edge for the <code>turn_off</code> event does not assign a value to a variable, so |
| variable <code>count</code> keeps its value when the lamp is turned off.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state space of this specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/discvar_change_state_space.png" alt="discvar change state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the name of the current location of automaton |
| <code>lamp</code> and the current value of variable <code>count</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-loc-var-duality1">Location/variable duality (1/2)</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The lesson that |
| <a href="#tut-data-chapter-discrete-variables">introduces discrete variables</a>, uses |
| an example of a counter. The actual count was modeled using a variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment, decrement; |
| |
| disc int count = 3; |
| |
| location: |
| edge decrement when count > 0 do count := count - 1; |
| edge increment when count < 5 do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It is also possible to use multiple locations instead of a variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment, decrement; |
| |
| location zero: |
| edge increment goto one; |
| |
| location one: |
| edge decrement goto zero; |
| edge increment goto two; |
| |
| location two: |
| edge decrement goto one; |
| edge increment goto three; |
| |
| location three: |
| initial; |
| |
| edge decrement goto two; |
| edge increment goto four; |
| |
| location four: |
| edge decrement goto three; |
| edge increment goto five; |
| |
| location five: |
| edge decrement goto four; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This alternate model has the same behavior, in that it models a counter that |
| can be incremented an decremented in steps of one, and the value is kept at |
| least zero, and at most five. The variant with the variable however, is shorter |
| and more intuitive. It is also easier to change to the <code>count < 5</code> guard to |
| <code>count < 100</code> than it is to add dozens of additional locations and edges. In |
| this case, using a variable is preferable to using multiple locations.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-loc-var-duality2">Location/variable duality (2/2)</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The lesson that <a href="#tut-basics-chapter-automata">introduces automata</a>, used an |
| example of a lamp:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp: |
| event turn_on, turn_off; |
| |
| location on: |
| initial; |
| edge turn_off goto off; |
| |
| location off: |
| edge turn_on goto on; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The automaton uses two locations to keep track of the current state of the |
| lamp. Instead of two locations, it is also possible to use a variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp: |
| event turn_on, turn_off; |
| |
| disc bool on = true; |
| |
| location: |
| initial; |
| edge turn_on when not on do on := true; |
| edge turn_off when on do on := false; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This alternate automaton uses a single variable named <code>on</code>. The |
| <a href="#tut-values-chapter-types-values-exprs">data type</a> of the variable is |
| <code>bool</code>, which means that the variable can only have one of two possible |
| values: <code>true</code> or <code>false</code>. If variable <code>on</code> has value <code>true</code>, the lamp |
| is on, and if it has value <code>false</code> it is off. Initially, the lamp is on, as |
| the initial value of the variable is <code>true</code>. The automaton has only one |
| location, with two edges. The first edge indicates that the lamp can be turned |
| on (event <code>turn_on</code>), only when it is not currently on (guard <code>not on</code>), |
| and then afterwards is on (variable <code>on</code> becomes <code>true</code>). Similarly, the |
| second edge indicates that the lamp can be turned off, only when it is |
| currently on, and then afterwards is on.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both models represent a lamp that is initially on, and can be turned off, |
| on, off again, on again, etc, repeating the behavior forever. Which approach |
| is best depends on your preference, and on the rest of the model. It is however |
| also possible to use both locations and a variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp: |
| event turn_on, turn_off; |
| |
| disc bool on2 = true; |
| |
| location on: |
| initial; |
| edge turn_off do on2 := false goto off; |
| |
| location off: |
| edge turn_on do on2 := true goto on; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This automaton has the same behavior as the previous two automata. Variable |
| <code>on</code> is renamed to <code>on2</code>, as a variable can not have the same name as a |
| location of that same automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>While it is possible to model a lamp like this, this automaton duplicates the |
| information about whether the lamp is on or off. This makes the automaton |
| larger and more complex than it needs to be. In general, it is usually better |
| to choose either a variable, or multiple locations, to express something, and |
| not both. In several future lessons, we’ll see that combining multiple |
| locations with variables is useful, but not to express the same thing. |
| Furthermore, an other future lesson explains how to |
| <a href="#tut-data-chapter-locs-as-var">use a location as a variable</a>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-read-write">Global read, local write</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Discrete variables can only be declared in automata, and may only be assigned |
| (given a value, written) by that automaton. They may however be read globally. |
| Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton customer: |
| location: |
| initial; |
| edge queue1.enter when queue1.count <= queue2.count; |
| edge queue2.enter when queue2.count <= queue1.count; |
| end |
| |
| automaton queue1: |
| event enter, leave; |
| |
| disc int count = 0; |
| |
| location: |
| initial; |
| edge enter when count < 2 do count := count + 1; |
| edge leave when count > 0 do count := count - 1; |
| end |
| |
| automaton queue2: |
| event enter, leave; |
| |
| disc int count = 0; |
| |
| location: |
| initial; |
| edge enter when count < 2 do count := count + 1; |
| edge leave when count > 0 do count := count - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models a supermarket, and features a customer and two |
| queues. Customers arrive and enter either of the queues. Eventually customers |
| leave the queue.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both queues (automata <code>queue1</code> and <code>queue2</code>) are identical, except for |
| their names. They maintain the <code>count</code>, which represents the number of |
| customers in the queue. A queues is full if it contains two customers. |
| Customers can thus only <code>enter</code> a queue if less than two customers are |
| present. Similarly, it is only possible for a customer to leave a queue if |
| there is a customer in the queue.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Customers decide to which queue they go, based on the number of customers |
| already present in those queues. A customer only enters the first queue if that |
| queue has less than or the same number of customers as the second queue. |
| Similarly, a customer only enters the second queue if that queue has less than |
| or the same number of customers as the first queue. If the queues have the same |
| number of customers, the customer can choose either queue.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The <code>enter</code> event declared in the first queue (<code>queue1</code>) is used by both |
| the <code>customer</code> automaton and the <code>queue1</code> automaton. The event is thus only |
| possible (enabled) if both automata can participate. Both automata restrict the |
| occurrence of the event using a guard. The event is thus only possible if both |
| guards hold. That is, a custom never enters the first queue if it is full, but |
| it also never enters that queue if it has more customers than the second queue.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state space of this specification is as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/supermarket_state_space.png" alt="supermarket state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the counts of the first and second queues.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>customer</code> automaton uses the values of the variables of the queue |
| automata, and thus reads variables of other automata. This is allowed, due to |
| the <em>global read</em> concept of CIF. This concept allows for short guards, that |
| directly and intuitively represent the condition under which an event may take |
| place.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The global read concept should only be used when it is intuitive. In the |
| supermarket example, the customer can physically see how many customers are |
| in the queues. It is therefore intuitive to directly refer to the <code>count</code> |
| variables of the queue automata. If however the customer would not be able to |
| physically observer the queues, then the customer would not be able to directly |
| base its decision of which queue to join, on that information. In that latter |
| case, it may not be a good idea to model the guard in such way.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <em>local write</em> concept means that discrete variables can only be written by |
| the automata in which they are declared. It is not allowed for the <code>customer</code> |
| and <code>queue2</code> automata to write (change the value of) the <code>count</code> variable |
| of the <code>queue1</code> automaton. Only the <code>queue1</code> automaton may write that |
| variable. The local write concept prevents that multiple automata write to the |
| same variable, as part of a synchronizing event, potentially causing |
| conflicting values to be assigned to that variable. This leads to several |
| benefits, most notably simpler semantics.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-monitoring">Monitoring</h4> |
| <div class="paragraph"> |
| <p> |
| |
| This lesson explains the concept of <em>monitoring</em>. It is explained using the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer: |
| event produce, provide_a, provide_b; |
| |
| location producing: |
| initial; |
| edge produce goto idle; |
| |
| location idle: |
| edge provide_a goto producing; |
| edge provide_b goto producing; |
| end |
| |
| automaton detect_changeover: |
| disc int count = 0; |
| |
| location start: |
| initial; |
| edge producer.provide_a goto a; |
| edge producer.provide_b goto b; |
| |
| location a: |
| edge producer.provide_b do count := count + 1 goto b; |
| |
| location b: |
| edge producer.provide_a do count := count + 1 goto a; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>producer</code> automaton represents a producer that can repeatedly |
| <code>produce</code> a product, and provide it to either consumer 'a' (event |
| <code>provide_a</code>) or consumer 'b' (event <code>provide_b</code>). The consumers are not |
| modeled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>detect_changeover</code> automaton detects consumer changes. That is, it |
| detects and counts how often the producer switching from providing consumer 'a' |
| with products to providing consumer 'b' with products, and vice versa. |
| Initially, the automaton waits for the first product to be provided. It goes |
| to either location <code>a</code> or location <code>b</code>, depending on which consumer is |
| provided that first product. Whenever a product is then provided to the other |
| consumer, the <code>count</code> is incremented by one to account for the changeover |
| taking place. This also switches the location to the location for the other |
| consumer, where once again the automaton waits for a changeover.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-the-monitoring-problem">The monitoring problem</h5> |
| <div class="paragraph"> |
| <p>There is a problem with the <code>detect_changeover</code> automaton. In its <code>a</code> |
| location, it disables the <code>provide_a</code> event, as there is no edge for that |
| event, and the automaton has that event in its (implicit) |
| <a href="#tut-basics-chapter-alphabet">alphabet</a>. This means that after a product is |
| provided to consumer 'a', no more products can be provided to that same |
| consumer, until the producer provides a product to the consumer 'b', and the |
| automaton switches to the corresponding <code>b</code> location. However, the idea is |
| that the producer can provide products to either consumer, at all times, as |
| that is the way it is intended. The <code>detect_changeover</code> automaton currently |
| prevents behavior that is present in the <code>producer</code>, while it is only meant |
| to <em>observe</em> or <em>monitor</em> products being provided. The state space of the |
| specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/monitoring_problem_state_space.png" alt="monitoring problem state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the first letters of the names of the current |
| locations of the automata. Note how the <code>i/a</code> and <code>i/b</code> locations only have |
| outgoing transitions for either the <code>provide_a</code> transition or the |
| <code>provide_b</code> transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-monitoring-with-self-loops">Monitoring with self loops</h5> |
| <div class="paragraph"> |
| <p>A simple solution is to allow the disabled events:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton detect_changeover: |
| disc int count = 0; |
| |
| location start: |
| initial; |
| edge producer.provide_a goto a; |
| edge producer.provide_b goto b; |
| |
| location a: |
| edge producer.provide_a; // Added self loop. |
| edge producer.provide_b do count := count + 1 goto b; |
| |
| location b: |
| edge producer.provide_a do count := count + 1 goto a; |
| edge producer.provide_b; // Added self loop. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The <code>provide_a</code> event has been added to an edge in the <code>a</code> location. The |
| edge is a <a href="#lang-tut-basics-shorter-notations-self-loop">self loop</a>, |
| meaning the current location of automaton <code>detect_changeover</code> does not change |
| as a result of taking the edge. This means that essentially the event is |
| ignored by the <code>detect_changeover</code> automaton, as the edge also has no |
| updates. The state space of the modified specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/monitoring_fixed_state_space.png" alt="monitoring fixed state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Now, whenever the <code>provide_a</code> event is possible, the <code>provide_b</code> event is |
| also possible, and vice versa, just as in the <code>producer</code> automaton. The |
| <code>detect_changeover</code> automaton no longer restricts the occurrence of the |
| events; it only monitors them.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-monitoring-with-monitor-automata">Monitoring with monitor automata</h5> |
| <div class="paragraph"> |
| <p>An alternative to adding self loops, is to use a <em>monitor</em> automaton. A monitor |
| automaton is an automaton that monitors or observes one or more events. The |
| events that it monitors, are never blocked (disabled) by that automaton. For |
| our producer/changeover example, we can turn the <code>detect_changeover</code> |
| automaton into a monitor automaton for the <code>provide_a</code> and <code>provide_b</code> |
| events:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton detect_changeover: |
| monitor producer.provide_a, producer.provide_b; // Monitor instead of the self loops. |
| |
| disc int count = 0; |
| |
| location start: |
| initial; |
| edge producer.provide_a goto a; |
| edge producer.provide_b goto b; |
| |
| location a: |
| edge producer.provide_b do count := count + 1 goto b; |
| |
| location b: |
| edge producer.provide_a do count := count + 1 goto a; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By default, automata don’t monitor any events. Using a <code>monitor</code> declaration |
| with one or more events, turns the automaton into a monitor automaton for those |
| events. For the producer/changeover example, the behavior with the monitor |
| automaton is exactly identical to the behavior of the specification with the |
| self loops.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By omitting the events from the <code>monitor</code> declaration, an automaton monitors |
| all events of its alphabet:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">monitor; // Monitor all events in the alphabet of the automaton.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For the producer/changeover, which has only the <code>provide_a</code> and <code>provide_b</code> |
| events in its alphabet, this would result in the same behavior as for the |
| automaton that monitors the two events explicitly.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using a monitor automaton instead of self loops has several advantages. A |
| monitor declaration has to be provided only once, while self loops often have |
| to be added to several locations. Furthermore, if the automaton is changed, it |
| may be necessary to add or remove self loops, while the monitor declaration can |
| most often be kept as is.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-asgn-old-vs-new">Old and new values in assignments</h4> |
| <div class="paragraph"> |
| <p>This lesson explains old and new values of variables in assignments, multiple |
| assignments, and the order of assignments.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-old-and-new-values">Old and new values</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment; |
| |
| disc int count = 0; |
| |
| location: |
| initial; |
| edge increment do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>counter</code> automaton represents a counter that starts counting at zero, |
| and can be incremented in steps of one.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| In assignments, the part to the left of the <code>:=</code> is called the <em>left hand |
| side</em> of the assignment, or the <em>addressable</em>. The addressable is the variable |
| that is assigned, and gets the new value. In the example above, variable |
| <code>count</code> is assigned a new value.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The part to the right of the <code>:=</code> is called the <em>right hand side</em> of the |
| assignment, or the (new) <em>value</em>. In the example above, the new value is |
| computed by taking the <em>current</em> or <em>old</em> value of variable <code>count</code> and |
| incrementing it by one.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, for variables used to compute the new value, always the old value |
| of those variables are used. The new values for variables after a transition, |
| are always computed from the old values of variables from before that |
| transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-data-asgn-old-vs-new-multiple">Multiple assignments</h5> |
| <div class="paragraph"> |
| <p>It is allowed to update multiple variables on a single edge, leading to |
| multiple variables getting a new value as part of a single transition. For |
| instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton swapper: |
| event swap; |
| disc int x = 0, y = 0; |
| |
| location: |
| initial; |
| edge swap do x := y, y := x + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>swapper</code> automaton declares two variables, <code>x</code> and <code>y</code>. It keeps |
| swapping the values of both variables, each time increasing the value of <code>y</code> |
| by one.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Initially, both variables have value zero. During the first <code>swap</code>, variable |
| <code>x</code> gets the value of variable <code>y</code>. Since the old values of the variables |
| are used to compute the new values, variable <code>x</code> remains zero. Variable <code>y</code> |
| gets the old value of variable <code>x</code>, which is also zero, incremented by one. |
| The result of the first swap is that <code>x</code> remains zero and <code>y</code> becomes one.</p> |
| </div> |
| <div class="paragraph"> |
| <p>During the second swap, <code>x</code> gets the value of variable <code>y</code>, which is then |
| one. Variable <code>y</code> gets the value of variable <code>x</code>, which was still zero |
| before the second swap, incremented by one. Both variables are thus one after |
| the second swap.</p> |
| </div> |
| <div class="paragraph"> |
| <p>During the third swap, <code>x</code> gets the value of variable <code>y</code> from after the |
| second swap, and thus remains one. Variable <code>y</code> becomes two.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state space of this somewhat artificial example is as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/swapper_state_space.png" alt="swapper state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the values of variables <code>x</code> and <code>y</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-assignment-order">Assignment order</h5> |
| <div class="paragraph"> |
| <p>It is important to note that since the new values of the variables are computed |
| from the old values of the variables, assignments are completely independent of |
| each other. In the example above, variable <code>x</code> is assigned a new value in the |
| first assignment, and variable <code>x</code> is also used to compute the new value of |
| variable <code>y</code>. However, the old value of variable <code>x</code> is used to compute the |
| new value of variable <code>y</code>. Therefore, the assignment to <code>x</code>, which |
| indicates how <code>x</code> should be given a new value, has no effect on the new value |
| off <code>y</code>, as the old value of <code>x</code> is used for that, regardless of whether |
| <code>x</code> is assigned a new value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since assignments are independent of each other, the order of the assignments |
| of the edge does not matter. Consider the following alternative edge:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge swap do y := x + 1, x := y;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The assignments to <code>x</code> and <code>y</code> have been reordered. The behavior of the |
| specification does not change as a result of this reordering.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-data-asgn-old-vs-new-multi">Multi-assignments</h5> |
| <div class="paragraph"> |
| <p>CIF supports both multiple assignments as well as multi-assignments. To see |
| the difference, consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge ... do x := y, y := x + 1; // Multiple (two) assignments. |
| edge ... do (x, y) := (y, x + 1); // Single multi-assignment.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first edge has multiple assignments, namely one assignment to variable |
| <code>x</code> and one assignment to variable <code>y</code>. The second edge has one assignment, |
| that gives new values to variables <code>x</code> and <code>y</code>. Both are identical, in that |
| they have the same affect: variable <code>x</code> is given the old value of variable |
| <code>y</code> and variable <code>y</code> is given the old value of variable <code>x</code> incremented |
| by one. Generally, using multiple assignments is preferred over using |
| multi-assignments, as the former is easier to read. However, in certain cases, |
| such as for <a href="#lang-tut-values-tuples-unpacking">tuple unpacking</a>, only the |
| latter variant can be used.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-event-synchronization-and-assignment-order">Event synchronization and assignment order</h5> |
| <div class="paragraph"> |
| <p>Consider a system with two conveyors. Products enter on the first conveyor, |
| and move towards the second conveyor. Once they leave the first conveyor, they |
| move onto the second one. Once they exit from the second conveyor, they leave |
| the system. The positions of the left sides of the boxes are in range zero to |
| seven, as indicated in the following figure:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/conveyor.png" alt="conveyor"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This system can be modeled using the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event move; |
| |
| automaton conveyor1: |
| monitor move; |
| event exit1; |
| disc int pos = 0; |
| |
| location: |
| initial; |
| edge move when pos < 4 do pos := pos + 1; |
| edge exit1 when pos = 4 do pos := 0; |
| end |
| |
| automaton conveyor2: |
| monitor move; |
| event exit2; |
| disc int pos = -1; |
| |
| location: |
| initial; |
| edge conveyor1.exit1 when pos = -1 do pos := conveyor1.pos; |
| edge move when pos >= 0 and pos < 7 do pos := pos + 1; |
| edge exit2 when pos = 7 do pos := -1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each conveyor is modeled using an automaton. Both conveyors use a <code>pos</code> |
| variable to represent the position of the left side of the box. The first |
| conveyor gets a new box as soon as one leaves. The second one has to wait for |
| a box from the first, and can thus be without a box. This is represented by |
| value <code>-1</code> for the <code>pos</code> variable from automaton <code>conveyor2</code>. The <code>-1</code> |
| value is not a actual position, but a special value indicating that no box is |
| present on the conveyor.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Boxes on the first conveyor can move towards the second conveyor (event |
| <code>move</code>), until they reach position 4. They then leave the first conveyor |
| (event <code>exit1</code>), and a new box immediately enters the first conveyor |
| (variable <code>pos</code> is reset to zero).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Boxes enter the second conveyor when they leave the first conveyor (event |
| <code>exit1</code> from <code>conveyor1</code>). The position of the box is then transferred from |
| the first conveyor to the second. The box keeps moving (event <code>move</code>) on |
| the second conveyor until it reaches position 7. At position 7 it leaves |
| (event <code>exit2</code>) the second conveyor, and the system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both automata synchronize over the <code>move</code> event, meaning that the boxes on |
| both conveyors move at the same time. Both automata |
| <a href="#tut-data-chapter-monitoring">monitor</a> that event to ensure it is never |
| blocked if only the other conveyor can actually move.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both automata synchronize over the <code>exit1</code> event. The first conveyor resets |
| is own position (variable <code>pos</code>) to zero. The second conveyor sets its own |
| position (variable <code>pos</code>) to the position of the first conveyor. Since old |
| values of variables are used to compute the new values, the new value of |
| variable <code>pos</code> in <code>conveyor2</code> is given the old value of variable <code>pos</code> |
| from <code>conveyor1</code>. This is not influenced by the assignment to variable |
| <code>pos</code> of <code>conveyor1</code> to zero, as assignments are independent, and the order |
| of assignments does not matter, just as for multiple assignments on a single |
| edge.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state space of this specification is as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/conveyor_state_space.png" alt="conveyor state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the values of the <code>pos</code> variables of the automata |
| for the first and second conveyors.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The important part of the state space is the transition from state <code>4/-1</code>, |
| where the box of the first conveyor is at the end and the second conveyor has |
| no box, to state <code>0/4</code>, where the first conveyor has received a new box at |
| position zero, and the second conveyor has taken over the box (and the |
| administration of its position) from the first conveyor.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-tau-event">The <code>tau</code> event</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| Events allow for synchronization, allowing for interaction between automata |
| based on events. If however an automaton has an edge that performs some |
| internal processing, the event may not always be relevant. Consider for |
| instance the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine1: |
| event process, provide; |
| disc int id = 0; |
| |
| location processing: |
| initial; |
| edge process do id := id + 1 goto providing; |
| |
| location providing: |
| edge provide goto processing; |
| end |
| |
| automaton machine2: |
| location: |
| initial; |
| edge machine1.provide; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The specification models two machines. Products enter the first machine, |
| which processes them (event <code>process</code>) and assigns them an <code>id</code>. The |
| machine them provides (event <code>provide</code>) them to the second machine. The |
| second machine currently just accepts the products provided by the first |
| machine, but would in reality likely perform its own processing as well. |
| The state space of the specification is as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/tau_event_state_space1.png" alt="tau event state space1"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the names of the current locations of automaton |
| <code>machine1</code>. Since automaton <code>machine2</code> has only a single location, its |
| current location does not change, and it is therefore not included in the state |
| names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>provide</code> event synchronizes over both automata, while the <code>process</code> |
| event is local to the first machine. The <code>process</code> event is not essential, |
| and could be left out:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine1: |
| event provide; // No more 'process' event. |
| disc int id = 0; |
| |
| location processing: |
| initial; |
| edge do id := id + 1 goto providing; // No more event on the edge. |
| |
| location providing: |
| edge provide goto processing; |
| end |
| |
| automaton machine2: |
| location: |
| initial; |
| edge machine1.provide; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By omitting the event from an edge, the <code>tau</code> is used for that edge. The |
| <code>tau</code> event is an event that is implicitly always present without declaring |
| it. The state space of this modified specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/tau_event_state_space2.png" alt="tau event state space2"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The <code>tau</code> event does not synchronize. You can think of this as each automaton |
| having its own local <code>tau</code> event, and since then they are different events, |
| they do not synchronize. If multiple automata can perform a transition for an |
| edge with the <code>tau</code> event, this leads to potential transitions for each of |
| those edges. Since they are all labeled with the <code>tau</code> event, it is |
| impossible to distinguish them solely based on their label. This is a form of |
| <a href="#tut-basics-chapter-non-determinism">non-determinism</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using the <code>tau</code> events saves having to declare a local event, and also saves |
| having to put that event on the edge. It thus leads to smaller specifications. |
| However, as explained above, if <code>tau</code> is used on multiple edges of multiple |
| automata, the different <code>tau</code> transitions can no longer be distinguished from |
| each other in the state space. The use of the <code>tau</code> event is thus always a |
| trade-off.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| It is also possible to explicitly use the <code>tau</code> event:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge tau goto ...;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>tau</code> event can thus be used instead of 'regular' events, and may even |
| be combined with 'regular' events on the same edge:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge provide, tau goto ...;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Omitting the events from an edge defaults to a single <code>tau</code> event, as shown |
| in one of the examples above.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-discvar-init">Initial values of discrete variables</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Discrete variables can be given an initial value with their declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x = 1;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The initial value may be omitted, leading to the default value of its data type |
| being used:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x; |
| disc bool y;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The default value of <a href="#tut-values-chapter-integers">integer typed</a> variables |
| is <code>0</code>. The default value of <a href="#tut-values-chapter-booleans">boolean typed</a> |
| variables is <code>false</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-data-discvar-init-multiple" class="paragraph"> |
| <p>It is possible to indicate that a variable has more than one potential initial |
| value:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x in {1, 2, 4};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This declares a variable <code>x</code> that has three potential initial values. |
| Variables can only have one value at a time, so an initial value has to be |
| chosen from the <a href="#tut-values-chapter-sets">set</a> of potential initial values. |
| In other words, initially the value of variable <code>x</code> is either <code>1</code>, <code>2</code>, |
| or <code>4</code>. For information on how to store multiple values in a single variable, |
| see the lessons on types and values, in particular those on |
| <a href="#tut-values-chapter-tuples">tuples</a>, <a href="#tut-values-chapter-lists">lists</a>, |
| and <a href="#tut-values-chapter-sets">sets</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-data-discvar-init-any" class="paragraph"> |
| <p>It is also possible to indicate that a variable can have any arbitrary initial |
| value:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x in any; |
| disc bool y in any;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>x</code> can initially have any value. The only constraint is that the |
| initial value must be an integer value, as it must conform to the integer type |
| (<code>int</code>) of the variable. Examples of initial values include <code>-1027</code>, |
| <code>0</code>, <code>1</code>, and <code>12345</code>. Variable <code>y</code> can initially have any value, as |
| long as that value is a boolean value, due to the variable having a boolean |
| type (<code>bool</code>). There are only two boolean values, <code>true</code> and <code>false</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Discrete variables with multiple potential initial values and arbitrary initial |
| values essentially <em>parametrize</em> the specification. The exact initial value is |
| to be chosen or <em>configured</em> later on. This allows a single specification to be |
| used for various different combinations of initial values.</p> |
| </div> |
| <div class="paragraph"> |
| <p>So far all examples used literal values to initialize the variables. However, |
| it is also allowed to use expressions to compute initial values, for instance |
| based on the initial values of other variables:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x = 1; // Initial value: 1 |
| disc int y = x * 2; // Initial value: 2 |
| disc int z = x + y; // Initial value: 3</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Variable <code>x</code> is explicitly initialized with value <code>1</code>. Variable <code>y</code> is |
| initialized to the initial value of <code>x</code>, multiplied by two. Variable <code>z</code> |
| is initialized to the sum of the initial values of <code>x</code> and <code>y</code>. Using this |
| kind of initialization is useful if the initial values must be kept consistent. |
| Changing the initial value of <code>x</code> automatically also changes the initial |
| values of <code>y</code> and <code>z</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The order of the declaration of the variables does not matter. We could just |
| as easily declare them as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int y = x * 2; // Uses variable x, which is declared later. |
| disc int x = 1;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Variable <code>y</code> is still initialized using the initial value of variable <code>x</code>, |
| which is now declared after variable <code>y</code>. It is not allowed to construct |
| loops, where the initial values of variables depend on each other:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x = y; // Invalid initial value due to cyclic dependency. |
| disc int y = z; |
| disc int z = x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>x</code> uses the value of variable <code>y</code>, which uses the value of |
| variable <code>z</code>, which in turn uses the value of variable <code>x</code> again. This is |
| not allowed in CIF, as it creates a cyclic dependency. However, since no |
| restrictions are introduced on the initial values of variables <code>x</code>, <code>y</code>, |
| and <code>z</code>, except that they must be equal to each other, we can declare them |
| as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x in any; // Explicit 'any' breaks the cyclic dependency. |
| disc int y = z; |
| disc int z = x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, variable <code>x</code> is explicitly initialized to an arbitrary value. The other |
| variables are initialized to be equal to whatever arbitrary value is chosen as |
| initial value for variable <code>x</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-init-preds">Initialization predicates</h4> |
| <div class="paragraph"> |
| <p> |
| <em>Initialization predicates</em> can be used to specify the allowed initial |
| locations of automata, as well as to restrict the allowed initial values of |
| variables.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-data-init-preds-aut">Initial locations of automata</h5> |
| <div class="paragraph"> |
| <p>Initialization predicates can be used to specify the allowed initial locations |
| of automata:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| location loc1: |
| initial; |
| |
| location loc2: |
| initial true; |
| |
| location loc3; |
| |
| location loc4: |
| initial false; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton <code>a</code> has four locations. Location <code>loc1</code> has the <code>initial</code> |
| keyword, and is thus allowed to be the initial location. Location <code>loc2</code> |
| also uses the <code>initial</code> keyword, but additionally specifies a predicate that |
| indicates under which conditions the location may be the initial location. |
| Since it is <code>true</code>, which always holds, it does not impose any additional |
| restrictions, and can thus always be the initial location. In fact, this is |
| identical to location <code>loc1</code>, which did not specify a predicate, in which |
| case it default to <code>true</code> as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Location <code>loc3</code> does not specify anything about initialization, and thus |
| can never be the initial location. Location <code>loc4</code> can only be the initial |
| location if <code>false</code> holds. Since <code>false</code> never holds, location <code>loc4</code> |
| can never be the initial location. In fact, this is identical to location |
| <code>loc3</code>, which did not specify any initialization at all, in which case it |
| default to <code>false</code> as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Locations <code>loc1</code> and <code>loc2</code> are the potential initial locations, |
| while locations <code>loc3</code> and <code>loc4</code> can not be chosen as initial locations of |
| automaton <code>a</code>. Since an automaton can only have one current location, an |
| initial location has to be chosen from the potential initial locations. In |
| other words, the initial location of automaton <code>a</code> is either location |
| <code>loc1</code> or location <code>loc2</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-consistency-between-initial-locations-and-initial-values">Consistency between initial locations and initial values</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton odd_even: |
| event inc, dec; |
| disc int n = 5; |
| |
| location odd: |
| initial; |
| edge inc do n := n + 1 goto even; |
| edge dec do n := n - 1 goto even; |
| |
| location even: |
| edge inc do n := n + 1 goto odd; |
| edge dec do n := n - 1 goto odd; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton <code>odd_even</code> keeps track of a value (<code>n</code>) that can constantly be |
| incremented (event <code>inc</code>) and decremented (event <code>dec</code>) by one. It has two |
| locations, that keep track of the <code>odd</code>/<code>even</code> status of value <code>n</code>. |
| Currently, the initial value is <code>5</code>, which is odd. Therefore, the <code>initial</code> |
| keyword is specified in the <code>odd</code> location. However, if we change the initial |
| value of variable <code>n</code> to <code>6</code>, we have to change the initial location |
| as well, to ensure consistent initialization. To automatically keep the initial |
| location consistent with the initial value of variable <code>n</code>, we can change |
| the specification to the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton odd_even: |
| event inc, dec; |
| disc int n = 5; |
| |
| location odd: |
| initial n mod 2 = 1; // Initial location if 'n' is odd. |
| edge inc do n := n + 1 goto even; |
| edge dec do n := n - 1 goto even; |
| |
| location even: |
| initial n mod 2 = 0; // Initial location if 'n' is even. |
| edge inc do n := n + 1 goto odd; |
| edge dec do n := n - 1 goto odd; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this specification, location <code>odd</code> can only be the initial location if |
| the value is odd (the value |
| <a href="http://en.wikipedia.org/wiki/Modular_arithmetic">modulo</a> |
| two is congruent to |
| one), and location <code>even</code> can only be the initial location if the value is |
| even. Changing the initial value of variable <code>n</code> then also changes the |
| potential initial locations. Since the value is always odd or even, and can’t |
| be both odd and even, automaton <code>odd_even</code> always has exactly one potential |
| initial location.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-restricting-initialization">Restricting initialization</h5> |
| <div class="paragraph"> |
| <p>Initialization predicates can also be used to restrict the initial values of |
| variables. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| disc int x in any; |
| |
| initial x mod 2 = 1; |
| |
| location ... |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this partial automaton, variable <code>x</code> can be initialized to any integer |
| value, as indicated by its <code>int</code> type and the <code>any</code> keyword. However, the |
| initialization predicate states that initially, the value of <code>x</code> module two |
| must be congruent to one. That is, the value of variable <code>x</code> must initially |
| be odd.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is allowed to specify initialization predicates inside automata, but it is |
| also allowed to place them outside of them:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| disc int x in any; |
| |
| location ... |
| end |
| |
| automaton b: |
| disc int x in any; |
| |
| location ... |
| end |
| |
| initial a.x = 2 * b.x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, two automata each declare a variable that can have arbitrary initial |
| values. The initialization predicate specifies that the initial value of |
| variable <code>x</code> from automaton <code>b</code> must be twice the initial value of |
| variable <code>x</code> from automaton <code>a</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is generally recommended to place an initialization predicate inside an |
| automaton if the condition only applies to declarations from that automaton, |
| and to place it outside of the automata if the condition applies to |
| declarations of multiple automata.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-locs-as-var">Using locations as variables</h4> |
| <div class="paragraph"> |
| <p> |
| Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine1: |
| event start1, done1, reset1; |
| disc bool claimed = false; |
| |
| location idle: |
| initial; |
| edge start1 when not machine2.claimed do claimed := true goto processing; |
| |
| location processing: |
| edge done1 do claimed := false goto cool_down; |
| |
| location cool_down: |
| edge reset1 goto idle; |
| end |
| |
| automaton machine2: |
| event start2, done2, reset2; |
| disc bool claimed = false; |
| |
| location idle: |
| initial; |
| edge start1 when not machine1.claimed do claimed := true goto processing; |
| |
| location processing: |
| edge done1 do claimed := false goto cool_down; |
| |
| location cool_down: |
| edge reset1 goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models two machines, which produce products. The machines |
| share a common resource, which may only be used by at most one of them, at any |
| time (see |
| <a href="http://en.wikipedia.org/wiki/Mutual_exclusion">mutual exclusion</a>). |
| Initially, the machines are <code>idle</code>. Then, they warm themselves up. Once they |
| start processing, they set their boolean variable <code>claimed</code> to <code>true</code> to |
| indicate that they claimed the shared resource. After processing, the machines |
| release the resource, by setting <code>claimed</code> to <code>false</code>. They finish their |
| processing cycle by cooling down, before starting the cycle for the next |
| product. To ensure that a machine can not claim the resource if the other |
| machine has already claimed it, the edges going to the <code>processing</code> locations |
| have a guard that states that it is only allowed to claim the resource and |
| start processing, if the other machine has not already claimed the resource. |
| The state space of this specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/data/mutex_state_space.png" alt="mutex state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the first letters of the names of the current |
| locations of the automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The specification can alternatively be modeled as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine1: |
| event start1, done1, reset1; |
| |
| location idle: |
| initial; |
| edge start1 when not machine2.processing goto processing; |
| |
| location processing: |
| edge done1 cool_down; |
| |
| location cool_down: |
| edge reset1 goto idle; |
| end |
| |
| automaton machine2: |
| event start2, done2, reset2; |
| |
| location idle: |
| initial; |
| edge start1 when not machine1.processing goto processing; |
| |
| location processing: |
| edge done1 cool_down; |
| |
| location cool_down: |
| edge reset1 goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>claimed</code> variables and corresponding updates have been removed, and the |
| guards no longer use those variables. Instead, the edge for the <code>start1</code> |
| event now refers to the <code>processing</code> location of automaton <code>machine2</code>. The |
| guard states that the first machine can perform the <code>start1</code> event, only if |
| the second machine is not currently in its <code>processing</code> location. In other |
| words, the guard states that the first machine can start processing as long as |
| the second machine is not currently busy processing (and thus using the shared |
| resource).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>processing</code> location of automaton <code>machine2</code> is used as a boolean |
| variable. Using the location as a variable saves having to declare another |
| variable (<code>claimed</code>) that essentially holds the same information, and needs |
| to be explicitly updated (on two separate edges) to the correct value.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-stat-invariants">State (exclusion) invariants</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The lesson on <a href="#tut-data-chapter-discrete-variables">discrete variables</a> used |
| the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment, decrement; |
| |
| disc int count = 3; |
| |
| location: |
| initial; |
| edge decrement when count > 0 do count := count - 1; |
| edge increment when count < 5 do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The counter can repeatedly be incremented and decremented by one, as long as |
| the count remains at least one and at most five. To keep the count in the |
| allowed range of values, guards were used to limit the occurrence of the |
| <code>increment</code> and <code>decrement</code> events.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Instead of using guards, it is also possible to use state (exclusion) |
| invariants, also called state invariants, or just invariants:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton counter: |
| event increment, decrement; |
| |
| disc int count = 3; |
| |
| invariant count >= 0; // Added invariants |
| invariant count <= 5; |
| |
| location: |
| initial; |
| edge decrement do count := count - 1; // No more guards |
| edge increment do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The guards on the edges have been replaced by the two invariants. The first |
| invariant specifies that the value of variable <code>count</code> must always be at |
| least zero. The second invariant specifies that the value must also be at most |
| five.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Invariants specify conditions that must always hold. Invariants must hold in |
| the initial state, and all states reached via transitions. If a transition |
| results in a state where an invariant doesn’t hold, the transition is not |
| allowed and can’t be taken.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the counter example, initially the <code>count</code> is <code>3</code>. The edge for the |
| <code>increment</code> event can be taken, leading to a state where the <code>count</code> is |
| <code>4</code>. Taking another transition for the <code>increment</code> event leads to a state |
| where the <code>count</code> is <code>5</code>. If we then were to take another transition for |
| the <code>increment</code> event, the <code>count</code> would then become <code>6</code>. However, that |
| violates the invariant. Therefore, in the state where the <code>count</code> is <code>5</code>, |
| no transition for the <code>increment</code> event is possible. In other words, the |
| invariant disables the transition for the <code>increment</code> event for that state.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The two invariants can be specified in various ways:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Multiple invariants, each with a single predicate. |
| invariant count >= 0; |
| invariant count <= 5; |
| |
| // Single invariant, with multiple predicates. |
| invariant count >= 0, count <= 5; |
| |
| // Single invariant, with single predicate. |
| invariant count >= 0 and count <= 5;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each of these variants leads to the exact same behavior, and which variant to |
| use depends mostly on the modeler’s own preference.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The benefit of guards over invariants is that they more explicitly state the |
| condition under which an edge can lead to a transition. If a guard doesn’t |
| hold, the edge can’t be part of a transition. It is thus immediately clear when |
| the edge can lead to a transition. For invariants, the update has to be |
| calculated first, after which the invariants can be evaluated for the state |
| resulting from the transition. If one of the invariants doesn’t hold, the |
| transition is not allowed. In the case of the invariants, it is not as |
| immediately clear from the edge alone, when that specific edge can or can not |
| lead to a transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The benefit of invariants over guards is that they apply to all edges. If |
| several edges in an automaton have updates to the same variable, then the |
| invariants need to be specified only once, and apply to all transitions, for |
| all edges. Using guards, all the edges that modify the variable would need |
| their own guards, and if the updates are different, the different edges usually |
| require different guards. Furthermore, if new edges with updates to the same |
| variables are added, the invariant is already present, but guards have to be |
| added, which can easily be forgotten. In those cases, invariants can thus help |
| keep the specification consistent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another benefit of invariants is that they explicitly state the conditions that |
| must hold in relation to the variables, while guards specify the condition |
| under which the update is allowed. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Using invariants. |
| automaton a: |
| disc int x; |
| |
| invariant 0 <= x, x <= 100; |
| |
| location: |
| initial; |
| edge do x := 2 * x + 3; |
| end |
| |
| // Using guards. |
| automaton a: |
| disc int x; |
| |
| location: |
| initial; |
| edge when x <= 48 do x := 2 * x + 3; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The goal is to keep the value of in the range [0..100]. The invariant is simple |
| and direct. The guard however, has to state the condition under which the |
| update does not violate the goal. That is, the upper bound has to be decreased |
| by three, and the result has to be divided by two, to get the highest value |
| (48) for which the update is still within the valid range of values. That is, |
| for value 48 the update results in value 99 (2 * 48 + 3 = 99), and for value |
| 49 the update results in value 101 (2 * 48 + 3 = 99). The more complex the |
| update, the harder it is to figure out the guard to use to keep satisfy the |
| goal.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You can of course also use <code>2 * x + 3 <= 100</code> as guard, instead of |
| <code>x <= 48</code>. However, this duplicates part of the update in the guard.</p> |
| </div> |
| <div class="paragraph"> |
| <p>So far, all invariants have been specified in automata. They may however also |
| be specified outside of the automata, similar to |
| <a href="#tut-data-chapter-init-preds">initialization predicates</a>. It is generally |
| recommended to place an invariant inside an automaton if the condition only |
| applies to declarations from that automaton, and to place it outside of the |
| automata if the condition applies to declarations of multiple automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Furthermore, invariants can be placed in a location. Such an invariant only has |
| to hold while the location in which it is specified is the current location of |
| its automaton.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-data-chapter-stat-evt-excl-invariants">State/event exclusion invariants</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| Consider an elevator, consisting of three parts: a motor to make the elevator |
| move up and down, a door that can be opened and closed to let passengers enter |
| and exit, and an emergency button that can be used to stop the elevator in |
| case of an emergency. The following CIF specification models the three parts:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton motor: |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end |
| |
| automaton door: |
| event open, close; |
| |
| location closed: |
| initial; |
| edge open goto opened; |
| |
| location opened: |
| edge close goto closed; |
| end |
| |
| automaton emergency_button: |
| event push, release; |
| |
| location released: |
| initial; |
| edge push goto pushed; |
| |
| location pushed: |
| edge release goto released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each part is modeled by an automaton. Since the automata don’t share any |
| events, they operate independently. What is missing, is a controller that |
| links the different automata, and controls them in a safe manner. Such a |
| controller restricts the behavior of the individual automata, allowing only |
| the combined behavior that is deemed desired. There are several ways to |
| restrict events, including introducing synchronization between the different |
| automata, and adding guards. The downside of these approaches it that they |
| require modification of the automata. What if we wanted to specify the |
| controller separately from the behavior of the physical system? We could |
| introduce an additional automaton, that synchronizes with the existing |
| automata. For instance, we could add the following to the CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton controller: |
| location: |
| initial; |
| edge motor.turn_on when door.closed and emergency_button.released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This controller introduces restrictions for the <code>turn_on</code> event of the |
| <code>motor</code>. In this particular case, the controller ensures that the motor may |
| only be turned on when both the door is closed and the emergency button is |
| released. By restricting the event, the controller prohibits the event from |
| taking place in certain states, ensuring that only the desired behavior |
| remains.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is nice that we can separate the description of the physical behavior of the |
| elevator from the controller that controls it. This separation of concerns may |
| make it easier to reason about the behavior, it may make it easier to adapt |
| the controller when the physical system doesn’t change, and it may make it |
| easier to reuse the model of the physical system for other purposes.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, modeling an automaton with a single location that must then also be |
| <code>initial</code> requires quite some syntax. State/event exclusion invariants can |
| serve the same purpose, but are often easier to use, shorter to write, and |
| more intuitive to read. Instead of the <code>controller</code> automaton, we can also |
| use the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">invariant motor.turn_on needs door.closed and emergency_button.released;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each state/event exclusion invariant restricts an event, preventing it from |
| happening in certain states. That is, the event is excluded from taking place |
| in certain states. In this case, the <code>turn_on</code> event of the <code>motor</code> |
| automaton needs the <code>door</code> to be in its <code>closed</code> location and the |
| <code>emergency_button</code> to be in its <code>released</code> location, for the event to be |
| allowed/enabled. For the states in which that condition doesn’t hold, the event |
| is disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The invariant consists of two conditions. It can also be written as two |
| separate state/event exclusion invariants, one for each condition:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Single state/event exclusion invariant. |
| invariant motor.turn_on needs door.closed and emergency_button.released; |
| |
| // Multiple state/event exclusion invariants. |
| invariant motor.turn_on needs door.closed; |
| invariant motor.turn_on needs emergency_button.released;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The second and third invariants lead to the same behavior as the first combined |
| invariant. The second invariant ensures that the event can only take place when |
| the door is closed, while the third invariant ensures that the event can only |
| take place when the emergency button is released. The second and third |
| invariants each indicate a necessary condition that must hold for the event to |
| be allowed/enabled. Together, they require that both conditions hold, for the |
| event to be allowed/enabled. If one of the conditions doesn’t hold, the event |
| will be disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>door</code> is either <code>opened</code> or <code>closed</code>. So far, we’ve required that |
| the door is closed to allow the motor to be turned on. We can also specify it |
| the other way around: to disallow the motor to be turned on, while the door is |
| opened:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// State/event exclusion invariant to specify when event is allowed/enabled. |
| invariant motor.turn_on needs door.closed; |
| |
| // State/event exclusion invariant to specify when event is disallowed/disabled. |
| invariant door.opened disables motor.turn_on;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Both invariants have the exact same effect. The first invariant only allows the |
| motor to be turned on while the door is closed, which means that it disallows |
| the motor to be turned on in all other situations, namely when the door is |
| opened. And that is exactly what is specified by the second invariant: when the |
| door is opened, turning the motor on is disallowed/disabled. In general, |
| state/event exclusion invariants can always be specified as a positive form |
| (allowed/enabled) and a negative form (disallowed/disabled). It is up to the |
| modeler to choose, based on considerations such as personal preference and |
| readability. Consider the following four alternative forms:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Single state/event exclusion invariant for enabling the event. |
| invariant motor.turn_on needs door.closed and emergency_button.released;</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Multiple state/event exclusion invariants for enabling the event. |
| invariant motor.turn_on needs door.closed; |
| invariant motor.turn_on needs emergency_button.released;</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Single state/event exclusion invariant for disabling the event. |
| invariant door.opened or emergency_button.pushed disables motor.turn_on;</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Multiple state/event exclusion invariants for disabling the event. |
| invariant door.opened disables motor.turn_on; |
| invariant emergency_button.pushed disables motor.turn_on;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each of the four forms has the exact same effect, but is written in a different |
| way.</p> |
| </div> |
| <div class="paragraph"> |
| <p>We already saw earlier that for state/event exclusion invariants that |
| introduce necessary conditions for an event to be enabled (the <code>needs</code> |
| variant), the conditions can be combined using an <code>and</code> operator to form a |
| combined condition, for a single invariant.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Here, we also see how in a similar way, state/event exclusion invariants that |
| introduce sufficient conditions for an event to be disabled (the <code>disabled</code> |
| variant) can be combined. Each of them individually has a condition, that if |
| satisfied disables the event, regardless of the other invariants. So, if one of |
| them disables the event, the event is disabled. To combine such invariants into |
| a single invariant, the conditions need to be combined using an <code>or</code> |
| operator, as shown above.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It may occur that multiple events need to be disabled for the same conditions. |
| Instead of writing multiple invariants with the same conditions, one for each |
| event, they can also be combined:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Two separate invariants with same condition, for different events. |
| invariant motor.turn_on needs emergency_button.released; |
| invariant door.close needs emergency_button.released; |
| |
| // Combined invariant, for multiple events. |
| invariant {motor.turn_on, door.close} needs emergency_button.released;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first two invariants have the same condition, but restrict different |
| events. The third invariant has the same condition, but restricts both events. |
| In general, for all state/event invariants, multiple events may be given, if |
| they share the same condition. The events must then be separated by spaces and |
| be enclosed in curly brackets (<code>{...}</code>).</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-types-and-values">Types and values</h3> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-types-values-exprs">Types, values, and expressions</h4> |
| <div class="paragraph"> |
| <p>This lesson explains the difference between types, values, and expressions. |
| These concepts have already been used in previous lessons, but this lesson |
| names them explicitly, and also explains the relations between them. |
| Furthermore, this lesson serves as an introduction for the coming lessons, |
| which rely heavily on these concepts. Consider the following declarations of |
| <a href="#tut-data-chapter-discrete-variables">discrete variables</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int x = 1; |
| disc int y = 2 * x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The first declaration declares a discrete variable named <code>x</code>, and the second |
| declaration declares a discrete variable named <code>y</code>. Both variables have an |
| <code>int</code> <em>data type</em>. A data type is usually just called a <em>type</em>, if there is |
| no confusion with other kinds of types. The type of a variable indicates the |
| potential or allowed values of the variable. Variable <code>x</code> is initialized to |
| <em>value</em> <code>1</code>. Variable <code>y</code> is initialized to twice the value of <code>x</code>, |
| meaning it is initialized to value <code>2</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Both <code>1</code> and <code>2 * x</code> are <em>expressions</em>. Expressions are combinations of |
| among others literal values (e.g. <code>1</code>), variables (e.g. <code>x</code>), and |
| operations (e.g. <code>*</code>) on them. Expressions can be <em>computed</em>, resulting in a |
| value. This is called <em>evaluation</em> of the expression.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Expression <code>2 * x</code> can be evaluated. Evaluating the expression results in |
| value <code>2</code> if the value of <code>x</code> is <code>1</code>, and in value <code>4</code> if the value of |
| <code>x</code> is <code>2</code>. Expressions can thus be evaluated to different values, |
| depending on the values of the variables that occur in them.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| <div id="lang-tut-values-types-values-exprs-literal" class="paragraph"> |
| <p>Expression <code>1</code> consists of only a single value, called a <em>literal</em> value |
| expression. Evaluation always results in that single value. Expression |
| <code>1 + 3</code> evaluates to value <code>4</code>. Even though it does not consist of only |
| just a literal, the value is the same for each evaluation. The expression |
| represents a <em>constant</em> value.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-overview">Values overview</h4> |
| <div class="paragraph"> |
| <p>The values of CIF (and their types) can be categorized into different |
| categories: elementary values, container values, and miscellaneous values. |
| Elementary values represent single values, such as a single number. Container |
| values represent multiple values. The different container values combine or |
| store the values in different ways. The elementary and container values are |
| described in the remainder of this part of the tutorial. The miscellaneous |
| values are special, and are explained later in the tutorial. The remainder of |
| this lesson gives an overview of the values available per category, along with |
| short descriptions of each of the different kinds of values.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Elementary values</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-values-chapter-booleans">Booleans</a></dt> |
| <dd> |
| <p>Represents truth values of for instance guards and other conditions. The |
| only two possible values are <code>true</code> and <code>false</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-integers">Integers</a></dt> |
| <dd> |
| <p>Represent integer numbers, such as <code>-123</code> and <code>5</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-enumerations">Enumerations</a></dt> |
| <dd> |
| <p>Represent enumerated values, which are collections of names each |
| representing a different value. For instance, a enumeration named |
| <code>color</code> could have values <code>red</code>, <code>green</code>, and <code>blue</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-reals">Reals</a></dt> |
| <dd> |
| <p>Represent real numbers, such as <code>1.56</code> and <code>-2.7e6</code> (scientific |
| notation for 2.7 million).</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-strings">Strings</a></dt> |
| <dd> |
| <p>Represent textual values, such as <code>"hello world"</code> and <code>"some text"</code>.</p> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Container values</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-values-chapter-tuples">Tuples</a></dt> |
| <dd> |
| <p>Tuples have two or more ordered values, each of which can have a different |
| type. For instance: <code>(1, true, 5.0)</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-lists">Lists</a></dt> |
| <dd> |
| <p>Lists have zero or more ordered values, each of which has the same type, |
| and possibly with duplicates. For instance: <code>[1, 5, 2, 1]</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-sets">Sets</a></dt> |
| <dd> |
| <p>Sets have zero or more unordered values, each of which has the same type, |
| and without any duplicates. For instance: <code>{1, 5, 2}</code>.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-values-chapter-dictionaries">Dictionaries</a></dt> |
| <dd> |
| <p>Dictionaries have keys and associated values. The keys are unique and each |
| map to a value. For instance: <code>{1: true, 2: false, 3: false}</code>.</p> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Miscellaneous values</strong></p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><a href="#tut-functions-chapter-functions-as-values">Functions</a></dt> |
| <dd> |
| <p>Functions take values and use them to compute other values, possibly using |
| complex and lengthy calculations.</p> |
| </dd> |
| <dt class="hdlist1"><a href="#tut-stochastics-chapter-intro">Distributions</a></dt> |
| <dd> |
| <p>Stochastic distributions allow for sampling, making it possible to produce |
| random values.</p> |
| </dd> |
| </dl> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-integers">Integers</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| Integers are whole numbers, numbers without a fractional part. Examples include |
| <code>-123</code> and <code>5</code>. The default value of integers (<code>int</code> type) is <code>0</code>. |
| Several standard arithmetic operators and functions are available to work with |
| integers, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">+9 // 9 |
| --9 // 9 |
| |
| 9 + 4 // 13 |
| 9 - 4 // 5 |
| 9 * 4 // 36 |
| 9 / 4 // 2.25 (result is a real number, not an integer number) |
| |
| 9 div 4 // 2 (9 / 4 = 2.25, so 4 fits at most two whole times in 9) |
| 9 mod 4 // 1 (the remainder of 9 div 4) |
| |
| pow(2, 4) // 16 (2 to the power of 4, or 2 * 2 * 2 * 2) |
| abs(-9) // 9 (absolute value) |
| min(9, 4) // 4 (minimum value) |
| max(9, 4) // 9 (maximum value)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Integer values can be compared to other integer values:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">x < y // less than |
| x <= y // less than or equal to |
| x = y // equal to |
| x != y // not equal to |
| x >= y // larger than or equal to |
| x > y // larger than</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-integer-ranges">Integer ranges</h4> |
| <div class="paragraph"> |
| <p> |
| |
| CIF can only represent <a href="#tut-values-chapter-integers">integer numbers</a> |
| (type <code>int</code>) in the range -2,147,483,648 (= -2<sup>31</sup>) to |
| 2,147,483,647 (= 2<sup>31</sup> - 1). Using values outside that range |
| results in the CIF model being invalid, and leads to runtime errors:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">ERROR: Integer overflow: 9999999 * 9999999.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It is possible in CIF to explicitly specify that only a sub range of the |
| integer values are allowed:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc int[3..7] x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| This variable <code>x</code> can only have integer values that are at least <code>3</code> and |
| at most <code>7</code>. Assigning any other value to <code>x</code> is not allowed. The default |
| value is not <code>0</code> but <code>3</code>, as that is the value closest to <code>0</code> that is in |
| the allowed range of values.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-reals">Reals</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| Reals or real numbers are numbers with a fractional part. Examples include |
| <code>1.56</code> and <code>-2.7e6</code> (scientific notation for 2.7 million). Real numbers |
| must either have a fraction or use the scientific notation, to distinguish them |
| from integer numbers. The default value of reals (<code>real</code> type) is <code>0.0</code>. |
| Several standard arithmetic operators and functions are available to work with |
| reals, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">+1.23 // 1.23 |
| --1.2 // 1.2 |
| |
| 1.5 + 0.5 // 2.0 |
| 1.5 - 0.5 // 1.0 |
| 1.5 * 0.5 // 0.75 |
| 1.5 / 0.5 // 3.0 |
| |
| pow(3.5, 2.0) // 7.0 (3.5 to to the power of 2, or 3.5 * 3.5) |
| abs(-1.5) // 1.5 (absolute value) |
| min(1.5, 0.5) // 0.5 (minimum value) |
| max(1.5, 0.5) // 1.5 (maximum value) |
| |
| sqrt(16.0) // 4.0 (square root) |
| cbrt(16.0) // 2.0 (cube root) |
| |
| sin(1.0) // 0.841... (sine) |
| cos(1.0) // 0.540... (cosine) |
| tan(1.0) // 1.557... (tangent) |
| |
| log(100.0) // 2.0 (logarithm to base 10) |
| ln(100.0) // 4.605... (natural logarithm)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Real values can be compared to other real values, as well as to integer values:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">x < y // less than |
| x <= y // less than or equal to |
| x = y // equal to |
| x != y // not equal to |
| x >= y // larger than or equal to |
| x > y // larger than</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Integer numbers can often be written where real numbers are expected. Real |
| values and integer values can also often be combined using arithmetic operators |
| and functions. Furthermore, it is possible to convert between them, e.g as |
| follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">sqrt(16) // 4.0 (16 interpreted as 16.0) |
| 1 + 0.5 // 1.5 (addition of an integer number and a real number) |
| max(0.5, 1) // 1.0 (maximum of an integer number and a real number) |
| |
| <real>1 // 1.0 (cast from integer to real, explicit conversion) |
| round(1.6) // 2 (round real to closest integer, half up) |
| ceil(0.7) // 1 (round real up to integer) |
| floor(0.7) // 0 (round real down to integer)</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-booleans">Booleans</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| Booleans represents truth values of for instance guards and other conditions |
| and properties. The only two possible values are <code>true</code> (condition or |
| property holds) and <code>false</code> (condition or property does not hold). The |
| default value of booleans (<code>bool</code> type) is <code>false</code>. Several standard |
| <a href="http://en.wikipedia.org/wiki/Logical_operator">logical operators</a> |
| are available to work with booleans, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">not x // inverse |
| |
| x and y // conjunction (both x and y must hold) |
| x or y // disjunction (either x, y, or both must hold) |
| x => y // implication (if x holds, y must hold) |
| |
| x = y // equal to |
| x != y // not equal to</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The condition <code>x < 3</code> evaluates to <code>true</code> if <code>x</code> is less than <code>3</code> and |
| to <code>false</code> if <code>x</code> is <code>3</code> or larger than <code>3</code>. The result is thus a |
| boolean value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Conditions can be combined. <code>x >= 3 and x <= 9</code> means that the value of <code>x</code> |
| must be both at least <code>3</code> and at most <code>9</code>. <code>x >= 3 or x <= 9</code> means that |
| the value of <code>x</code> must be at least <code>3</code>, at most <code>9</code>, or both. Since the |
| condition is always satisfied (it always evaluates to <code>true</code>), condition |
| <code>true</code> can be used instead of <code>x >= 3 or x <= 9</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-strings">Strings</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| Strings represent textual values, as a sequence of characters. String values |
| are always written between double quotes. An example is <code>"hello world"</code>. The |
| default value of strings (<code>string</code> type) is the empty string <code>""</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Strings can be composed using the <code>+</code> operator. The expression |
| <code>"hello" + " " + "world"</code> evaluates to <code>"hello world"</code>. For advanced text |
| formatting, see |
| <a href="#tools-cifsim-output-print-chapter-tut-fmt">the text formatting tutorial</a>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-enumerations">Enumerations</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| Enumerations represent collections of related entities, such as types of |
| products, types of available resources, available machine types, different |
| countries, different colors, different genders, and so on. It is possible to |
| use numbers to represent the different entities, for instance <code>0</code> for red, |
| <code>1</code> for orange, and <code>2</code> for green, to represent the different colors of |
| a traffic light. However, these numbers are rather arbitrary. Furthermore, they |
| don’t actually represent numbers, but rather they represent one of the entities |
| (red, orange, green). Enumerations allow giving each entity a name, and to use |
| those names instead of numbers. This usually makes the model easier to read and |
| understand. For instance, consider the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum TrafficColor = RED, ORANGE, GREEN;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="lang-tut-values-enums-lit" class="paragraph"> |
| <p>The <code>enum</code> keyword is used to declare an enumeration. The <code>TrafficColor</code> |
| enumeration has three possible values or <em>literals</em>. The literals are named |
| <code>RED</code>, <code>ORANGE</code>, and <code>GREEN</code>. An enumeration can be used as data type, |
| and the enumeration literals can be used as values:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc TrafficColor light = RED;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>TrafficColor</code> enumeration is used as type of the <code>light</code> variable. |
| The <code>light</code> variable is given value <code>RED</code> as its initial value. The default |
| value of an enumeration type is its first literal (<code>RED</code> in this case). |
| However, it is usually preferred to explicitly initialize variables with |
| enumeration types, for readability.</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge change_color when light = RED do light := GREEN;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This edge has a guard that compares the value of the <code>light</code> variable to |
| enumeration literal <code>RED</code>. Only if the <code>light</code> is currently <code>RED</code>, may |
| this edge be taken. The edge further assigns enumeration literal <code>GREEN</code> as |
| the new value of variable <code>light</code>. The edge as a whole models that if the |
| <code>light</code> is currently <code>RED</code>, it may change color (event <code>change_color</code>) |
| and become <code>GREEN</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-tuples">Tuples</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| Tuples are used for keeping several (related) kinds of data together in one |
| variable, e.g. the identification number and weight of a box. A tuple consists |
| of a number of fields, where the types of these fields may be different. The |
| number of fields is fixed. For instance, consider the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>box</code> has a tuple type, consisting of two fields, an integer |
| typed field with name <code>nr</code> and real typed field with name <code>weight</code>. The |
| <code>box</code> variable has essentially two values, an integer typed value, and |
| a real typed value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If multiple consecutive fields have the same type, the type need not be |
| repeated for each of them. In the following example, variables <code>x1</code> and |
| <code>x2</code> have the same type:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int a; int b; real c; int d) x1; |
| disc tuple(int a, b; real c; int d) x2;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Literal values exist for tuple types:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box = (5, 2.7); |
| |
| edge ... do box := (6, 3.4);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>box</code> variable is initialized to a tuple value consisting of integer |
| value <code>5</code> (identification number) and real value <code>2.7</code> (weight). The entire |
| value of the variable is reassigned in the assignment. That is, both fields are |
| given new values.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| It is also possible to refer to a specific field of a tuple, using |
| <em>projection</em>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box = (5, 2.7); |
| disc int i; |
| disc real r; |
| |
| edge ... do i := box[nr]; // Projection to field 'nr'. |
| edge ... do r := box[weight]; // Projection to field 'weight'. |
| edge ... do box[nr] := i; // Assignment to field 'nr'. |
| edge ... do box[nr] := box[nr] + 1; // Increment of field 'nr'.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first edge uses projection to obtain the value of the integer <code>nr</code> |
| field, and assign it to integer variable <code>i</code> (<code>i</code> becomes <code>5</code>). The |
| second edge performs a similar operation for the <code>weight</code> field (<code>r</code> |
| becomes <code>2.7</code>). The third edge assigns the value of integer variable <code>i</code> |
| to the integer field <code>nr</code> of the <code>box</code> variable. This changes only the |
| value of the <code>nr</code> field. The value of the <code>weight</code> field of the <code>box</code> |
| variable is not affected by this assignment. The third edge increments the |
| value of the <code>nr</code> field of the <code>box</code> variable by one, leaving the |
| <code>weight</code> of the <code>box</code> as is. Besides projection using field names, it is |
| also possible to do projection using 0-based indices:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box = (5, 2.7); |
| disc int i; |
| disc real r; |
| |
| edge ... do i := box[0]; // Projection to field 'nr'. |
| edge ... do r := box[1]; // Projection to field 'weight'.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Index <code>0</code> refers to the first field, in this case field <code>nr</code>. Index <code>1</code> |
| refers to the second field, etc. Projection using indices is also called |
| <em>indexing</em>. For tuples, it is usually preferred to use field names, rather than |
| indices, for readability.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| It is possible to create a tuple from separate values, each stored in a |
| variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box; |
| disc int i; |
| disc real r; |
| |
| edge ... do box := (i, r); // Packing a tuple.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The right hand side of the assignment is a tuple literal value, as used before. |
| The field values however, are obtained by evaluation of variables, rather than |
| using literal integer and real values. This kind of assignment, where there is |
| tuple variable at the left hand side, and values for each of the fields of that |
| tuple at the right hand side, is called <em>packing</em> a tuple.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-values-tuples-unpacking" class="paragraph"> |
| <p>It is possible to obtain the values of the fields of a tuple into separate |
| variables:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc tuple(int nr; real weight) box = (5, 2.7); |
| disc int i; |
| disc real r; |
| |
| edge ... do i := box[nr], r := box[weight]; |
| edge ... do (i, r) := box; // Unpacking a tuple.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first edge uses projection on the variable <code>box</code> to obtain the values of |
| the individual fields, and assigns those extracted values to two separate |
| variables. The second edge does the same thing as the first edge, and is |
| preferred in this case, because of its simple and short notation. This kind of |
| use, where at the left hand side of the assignment you see variables for each |
| of the fields of the tuple, and on the right hand side you see only one |
| variable that has a tuple type, is called <em>unpacking</em> a tuple.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-lists">Lists</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| A list is an ordered collection of values (called <em>elements</em>) of a same type. |
| Lists can be used to model anything where duplicate values may occur or where |
| order of the values is significant. Examples are customers waiting in a shop, |
| process steps in a recipe, or products stored in a warehouse. Consider the |
| following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list int x = [7, 8, 3];</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="lang-tut-values-list-literal" class="paragraph"> |
| <p>Variable <code>x</code> has a list of integers as its value. In this case, its initial |
| value is a literal list with three integer elements. Lists are ordered |
| collections of elements. <code>[7, 8, 3]</code> is thus a different list as |
| <code>[8, 7, 3]</code>. Lists are empty by default, and they may have duplicate |
| elements:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list int x1; // Implicitly empty list. |
| disc list int x2 = []; // Explicitly empty list. |
| disc list int x3 = [1, 2, 1, 2, 2]; // Duplicate elements in a list.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Since lists are ordered, there is a first element and a last element (unless |
| the list is empty). An element can be obtained by <em>projection</em>, usually called |
| <em>indexing</em> for lists:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list int x = [7, 8, 3]; |
| disc int i; |
| |
| edge ... do i := x[0]; // 'i' becomes '7' |
| edge ... do i := x[1]; // 'i' becomes '8' |
| edge ... do i := x[2]; // 'i' becomes '3' |
| edge ... do i := x[3]; // error (there is no fourth element in the list) |
| edge ... do x[0] := 5; // the first element of 'x' is replaced by '5'</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first three edges obtain specific elements of the list, and assign them to |
| variable <code>i</code>. The first element is obtained using <em>index</em> or <em>offset</em> <code>0</code>, |
| the second element using index <code>1</code>, etc. The index of the last element is the |
| length of the list (the number of elements in the list), minus one. Indexing |
| does not change the value of variable <code>x</code>. The fourth edge is invalid, as |
| the fourth element (index <code>3</code>) of variable <code>x</code> is used, which does not |
| exist. The fifth edge replaces only the first element (index <code>0</code>) of list |
| <code>x</code>, while keeping the remaining elements as they are. It is also allowed to |
| use negative indices:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list int x = [7, 8, 3]; |
| disc int i; |
| |
| edge ... do i := x[-1]; // 'i' becomes '3' |
| edge ... do i := x[-2]; // 'i' becomes '8' |
| edge ... do i := x[-3]; // 'i' becomes '7' |
| edge ... do i := x[-4]; // error (there is no element before element '7')</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Negative indices start from the back of the list, rather than from the front. |
| Index <code>-1</code> thus always refers to the last element, <code>-2</code> to the second to |
| last element, etc. As with the non-negative indices, using a negative index |
| that is out of range of available elements, results in an error. To obtain a |
| non-negative index from a negative index, add the negative index to the length |
| of the list: <code>3 + -1 = 2</code>, <code>3 + -2 = 1</code>, and <code>3 + -3 = 0</code>. The following |
| figure visualizes a list, with non-negative indexing (at the top) and negative |
| indexing (at the bottom):</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/values/list_indices.png" alt="list indices"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Besides obtaining a single element from a list, it is also possible to obtain |
| a sub-range of the elements of a list, called a <em>slice</em>. Slicing also does not |
| change the contents of the list. It results in a copy of a contiguous |
| sub-sequence of the list. The result of a slice operation is again a list, even |
| if the slice contains just one element, or no elements at all. Slicing requires |
| two indices: the index of the first element of the sub-range (inclusive), and |
| the index of the last element of the sub-range (exclusive). Both indices may be |
| omitted. If the start index is omitted, it defaults to zero. If the end index |
| is omitted it defaults to the length of the list. If the begin index is equal |
| to or larger than the end index, the slice is empty. Similar to indexing, |
| negative indices may be used, which are relative to the end of the list rather |
| than the start of the list. Indices that are out of bounds |
| <a href="http://en.wikipedia.org/wiki/Saturation_arithmetic">saturate</a> to those |
| bounds. Some examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list int x = [7, 8, 3, 5, 9]; |
| |
| x[2:4] // [3, 5] Slice that includes third and fourth elements. |
| x[2:7] // [3, 5, 9] Slice that excludes the first two elements. |
| x[1:] // [8, 3, 5, 9] Slice that excludes the first element. |
| x[:-1] // [7, 8, 3, 5] Slice that excludes the last element. |
| x[:] // [7, 8, 3, 5, 9] Slice includes all elements (is equal to 'x').</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first slice takes the third (index <code>2</code>) and fourth (index <code>3</code>) |
| elements. The begin index (<code>2</code>) is thus included, the end index (<code>4</code>) is |
| not. The second slice starts at the same index, but extends to the sixth |
| element (index <code>7</code>). Since there are only five elements, the index is |
| saturated (or clamped) to the end of the list. The results is that all but the |
| first two elements are included. The third slice excludes the first element |
| (index <code>0</code>), by starting at index <code>1</code>. It omits the end index, meaning that |
| the entire remainder of the list is kept, and only the first element is not |
| included. The fourth slice begins at the beginning of the list, as the begin |
| index is omitted. It continues until the last element of list, which it |
| excludes. It thus excludes a single element from the end of the list. The fifth |
| slice includes all elements, as both the begin and end index are omitted. The |
| slice is thus identical to the list in <code>x</code>. The following figure graphically |
| represents the slices:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/values/list_slicing.png" alt="list slicing"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Lists can be combined into new lists. They are essentially 'glued' together. |
| This is called <em>concatenation</em>. This can also be used to add a single element |
| to the front or back of the list. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">[7, 8, 3] + [5, 9] // [7, 8, 3, 5, 9] |
| [5] + [7, 8, 3] // [5, 7, 8, 3] |
| [7, 8, 3] + [5] // [7, 8, 3, 5]</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Several other standard operators and functions are available to work with |
| lists, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">[1, 4, 2, 4, 5] - [2] // [1, 4, 4, 5] (removal of elements) |
| [1, 4, 2, 4, 5] - [4] // [1, 2, 4, 5] |
| [1, 4, 2, 4, 5] - [8] // [1, 4, 2, 4, 5] |
| [1, 2, 3, 4, 5] - [6, 4, 2, 3] // [1, 5] |
| [1, 4, 4, 1, 1] - [1, 4, 1] // [4, 1] |
| |
| [1, 8, 3] = [1, 3, 8] // false (equality test) |
| 6 in [1, 8, 3] // false (element test) |
| 1 in [1, 8, 3] // true |
| |
| empty([1, 2]) // false (empty test) |
| size([1, 5, 3, 3]) // 4 (count elements) |
| |
| del([7, 8, 9, 10], 2) // [7, 8, 10] (removed value at index '2') |
| pop([1, 5, 3]) // (1, [5, 3]) (first element and remainder)</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-bounded-lists-and-arrays">Bounded lists and arrays</h4> |
| <div class="paragraph"> |
| <p> |
| |
| CIF can only represent <a href="#tut-values-chapter-lists">lists</a> (type <code>list</code>) |
| with at most 2,147,483,647 (= 2<sup>31</sup> - 1) elements. Using lists |
| with more elements results in the CIF model being invalid, and leads to runtime |
| errors. For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| disc list int x; |
| |
| location: |
| initial; |
| edge do x := x + [1]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each time the edge is taken, another element is added to list <code>x</code>. As soon |
| as an attempt is made to add the 2,147,483,648<sup>th</sup> element, a |
| runtime error occurs.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is possible to explicitly restrict the number of elements that may be |
| contained in a list:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list[3..7] int y; // List with at least 3 and at most 7 elements.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Variable <code>y</code> can only have lists as its value that have at least <code>3</code> and at |
| most <code>7</code> elements. Assigning a list with any other number of elements is not |
| allowed. Lists with size restrictions are called <em>bounded lists</em>. They can also |
| be called <em>size restricted lists</em> or <em>ranged lists</em>. The default value for |
| <code>y</code> is <code>[0, 0, 0]</code>. That is, the default value has the least amount of |
| elements that is allowed by the bounded list, and the default value (<code>0</code>) of |
| the element type (<code>int</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="lang-tut-values-array" class="paragraph"> |
| <p>Lists with a fixed length are called <em>arrays</em>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc list[5..5] int a; // List with at least 5 and at most 5 elements. |
| disc list[5] int b; // Shorter but equivalent array notation.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By giving a bounded list the same lower and upper bound, the bounded list has a |
| fixed number of elements, and can be called an <em>array</em>. Arrays also have a |
| shorter and more convenient notation, where the number of elements is only |
| given once. Both notations for arrays are equivalent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both bounded lists and arrays support the same operations as regular lists, and |
| can be modified (assigned) the same way as regular lists, as long as their size |
| restrictions are not violated.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-sets">Sets</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| A set is an unordered collection of values (called <em>elements</em>) of a same type. |
| Each element value either exists in a set, or it does not exist in a set. Each |
| element value is unique, as duplicate elements are silently discarded. Consider |
| the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc set int x1 = {3, 7, 8}; |
| disc set int x2 = {8, 3, 7}; // Order irrelevant (same as 'x1'). |
| disc set int x3 = {8, 3, 7, 3}; // Duplicates ignored (same as 'x2'). |
| disc set int x4 = {}; // Empty set.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Variable <code>x1</code> has a set of integers as its value. In this case, its initial |
| value is a literal set with three integer elements. As sets are unordered |
| collections of elements, <code>{3, 7, 8}</code> is the same set as <code>{8, 3, 7}</code>, and |
| thus variables <code>x1</code> and <code>x2</code> have the same initial values. Since elements |
| in a set are unique, set <code>{8, 3, 7}</code> is equal to the set <code>{8, 3, 7, 3}</code>, |
| and thus variables <code>x2</code> and <code>x3</code> have the same initial values. For |
| readability, elements in a set are normally written in increasing order, for |
| example <code>{3, 7, 8}</code>. Variable <code>x4</code> has an empty set as initial value, which |
| is also the default initial value for sets.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The <em>union</em> of two sets results in a set that contains the combined elements of |
| both sets. You can think of the resulting set containing the elements that are |
| in the one set <code>or</code> in the other set (or in both of them). Since sets never |
| contain duplicates, common elements are present only once in the resulting set:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">{1, 2, 3} or {2, 3, 4} // {1, 2, 3, 4} |
| {1, 2, 3} or {2, 3, 4} // {1, 2, 4, 3}</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Since sets are unordered, both answers are possible, and represent the same |
| set. Since the order is irrelevant, there are 24 different ways to represent |
| that same set. In the remainder of this lesson, we’ll use increasing order, for |
| readability.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The <em>intersection</em> of two sets results in a set that contains the elements that |
| are present in both sets. You can think of the resulting set containing the |
| elements that are in the one set <code>and</code> in the other set. In other words, the |
| result contains the elements common to both sets:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">{1, 2, 3} and {2, 3, 4} // {2, 3} |
| {1, 2} and {3, 4} // {} (no elements in common)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The <em>difference</em> of two sets results in a set that contains the elements of the |
| first set that are not present in the second set. You can think of the |
| resulting set containing the elements of the first set, with the elements of |
| the second set subtracted or removed from it:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">{1, 2, 3} - {2, 3, 4} // {1} |
| {1, 2, 3} - {4, 5} // {1, 2, 3} |
| {1, 2, 3} - {1, 2, 3, 4} // {}</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Several other standard operators and functions are available to work with |
| sets, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">{1, 8, 3} = {1, 3, 8} // true (equality, ignores order of elements) |
| |
| 6 in {1, 8, 3} // false (element test) |
| 1 in {1, 8, 3} // true |
| |
| {1, 3} sub {1, 3} // true (subset check) |
| {1, 3} sub {1, 3, 5} // true |
| {1, 3} sub {1, 4} // false |
| {1, 3} sub {1, 4, 5} // false |
| |
| empty({1, 2}) // false (empty test) |
| size({1, 5, 3, 3}) // 3 (count elements, duplicates ignored)</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-dictionaries">Dictionaries</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| A dictionary is an unordered collection of <em>keys</em> and associated <em>values</em>. A |
| key with its associated value is called a key/value <em>pair</em>. Consider the |
| following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(string:int) age = {"eve": 32, "john": 34, "adam": 25};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Variable <code>age</code> has as value a dictionary consisting of pairs of strings |
| (the keys) and integers (the values). In this example, each string represents |
| a person’s name, and each integer represents the age of that person. Variable |
| <code>age</code> is initialized with a literal dictionary, containing three key/value |
| pairs. You can think of the dictionary as storing the information that <code>eve</code> |
| is <code>32</code> years old, or that the age of <code>eve</code> is <code>32</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As with sets, dictionaries are unordered. The order of the key/value pairs is |
| irrelevant, <code>{"eve": 32, "adam": 25}</code> is the same dictionary as |
| <code>{"adam": 25, "eve": 32}</code>. For readability, key/value pairs of dictionary |
| literals are normally written in increasing order of their keys. |
| <code>{"adam": 25, "eve": 32}</code> is thus preferred over <code>{"eve": 32, "adam": 25}</code>, |
| as <code>adam</code> goes before <code>eve</code> in a phone book.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Dictionary literals are often written using multiple lines, to get two |
| 'columns' for the keys and values, which can improve readability:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(string:int) age = {"eve": 32, |
| "john": 34, |
| "adam": 25};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The default value for dictionary types, is an empty dictionary. The following |
| two variables thus have the same initial value:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(string:int) x1 = {}; // Explicitly initialized as empty. |
| disc dict(string:int) x2; // Implicitly initialized as empty.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Every key of a dictionary is unique, but they may be associated with the same |
| value. For the above example with ages, the names (keys) are used to uniquely |
| identify people, but multiple people may have the same age (values). It is not |
| allowed to have the same key twice, in a dictionary literal, regardless of |
| whether they map to the same value or to different values:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(int:int) x1 = {1: 2, 1: 2}; // Invalid due to duplicate key '1'. |
| disc dict(int:int) x2 = {1: 2, 1: 3}; // Invalid due to duplicate key '1'.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The values of a dictionary can be obtained by <em>projection</em> on that dictionary, |
| using the keys:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(string:int) age = {"adam": 25, "eve": 32, "john": 34}; |
| disc int i; |
| |
| edge ... do i := age["adam"]; // 'i' becomes '25' |
| edge ... do i := age["eve"]; // 'i' becomes '32' |
| edge ... do i := age["carl"]; // error (there is no "carl" key)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Projection using a key that exists in the dictionary, results in the associated |
| value. Projection using a key that does not exist in the dictionary, leads to |
| a runtime error.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is possible to modify single elements of a dictionary, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(string:int) age = {"adam": 25, "eve": 32, "john": 34}; |
| |
| edge ... do age["eve"] := 33; // Changes eve's age. |
| edge ... do age["bob"] := 47; // Adds a new key/value pair.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The age of <code>eve</code> is changed from <code>32</code> to <code>33</code>. The age is thus replaced |
| by a new age. The age of <code>bob</code> is set to <code>47</code>. Since there was no key/value |
| pair for that person in the dictionary, a new key/value pair is added. After |
| the updates of both edges, the value of variable <code>age</code> is |
| <code>{"adam": 25, "bob": 47, "eve": 33, "john": 34}</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Several other standard operators and functions are available to work with |
| dictionaries, including the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">{"a": 1, "b": 2} = {"b": 2, "a": 1} // true (equality check) |
| {"a": 1, "b": 2} = {"a": 1, "b": 3} // false |
| |
| "a" in {"a": 1, "b": 2} // true (key existence check) |
| "c" in {"a": 1, "b": 2} // false |
| |
| {"a": 1, "b": 2} + {"b": 3, "c": 4} // {"a": 1, "b": 3, "c": 4} (add/overwrite pairs) |
| |
| {"a": 1, "b": 2} - {"b": 3, "c": 4} // {"a": 1} (removal based on keys) |
| {"a": 1, "b": 2} - {"b", "c"} // {"a": 1} |
| {"a": 1, "b": 2} - ["b", "c"] // {"a": 1} |
| |
| empty({"a": 1, "b": 2}) // false (empty check) |
| size({"a": 1, "b": 2}) // 2 (count pairs)</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-values-chapter-combining-values">Combining values</h4> |
| <div class="paragraph"> |
| <p>Values of different types can usually be arbitrarily combined. For instance, |
| consider the following example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">disc dict(int;tuple(real pos, weight)) boxes = {1: (0.0, 2.5), |
| 2: (3.0, 1.7), |
| 3: (4.0, 3.9};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>boxes</code> stores data about multiple boxes, in a dictionary with |
| unique identification numbers (<code>1</code>, <code>2</code>, and <code>3</code>) used as keys. For each |
| box, the position (<code>pos</code>) and <code>weight</code> are stored as a tuple. Initially, |
| there are three boxes. The first box has identification number <code>1</code>, |
| position <code>0.0</code>, and weight <code>2.5</code>. The second box has identification number |
| <code>2</code>, position <code>3.0</code>, and weight <code>1.7</code>. Also consider the following |
| example, where the data of that variable is manipulated:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">edge ... do boxes[1][weight] := 3.5; |
| edge ... do boxes[2][pos] := boxes[2][pos] + 1; |
| edge ... do boxes[4] := (1.0, 0.8);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first edge changes the <code>weight</code> of the box <code>1</code> (the box with |
| identification number <code>1</code>), from <code>2.5</code> to <code>3.5</code>. The second edge |
| increases the position (<code>pos</code>) of box <code>2</code> from <code>3.0</code> to <code>4.0</code>. The |
| third edge adds data for a new box with identification number <code>4</code>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-scalable-solutions-and-reuse-12">Scalable solutions and reuse (1/2)</h3> |
| <div class="sect3"> |
| <h4 id="tut-reuse1-chapter-constants">Constants</h4> |
| <div class="paragraph"> |
| <p> |
| Through the use of <em>constants</em>, fixed values can be given a name. Using |
| constants, it is easy to change certain fixed values. If the constant is |
| used consistently throughout the model, the value needs to be changed only in |
| one place. Constants can thus make it easier to keep the model consistent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int STEP = 2; |
| const int TARGET = 100; |
| |
| automaton movement: |
| disc int position = 0; |
| event move; |
| |
| location: |
| initial; |
| edge move when position < TARGET do position := position + STEP; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this example, the <code>movement</code> automaton keeps track of the <code>position</code> of |
| an object. The object starts at position <code>0</code>. It can <code>move</code> until it |
| reaches its target position. The target position is <code>100</code>. Rather than using |
| <code>position < 100</code> as guard, the value <code>100</code> is stored in a constant named |
| <code>TARGET</code>. The constant can then be used instead the value <code>100</code>. Similarly, |
| the step size of the object is stored in a constant named <code>STEP</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Constants have a name, which by contention is usually written using upper case |
| letters. Using a constant instead of a fixed value makes it more clear what |
| that value represents. For instance, by using <code>position < TARGET</code> rather than |
| <code>position < 100</code>, the intention of the guard condition is more clear. Using a |
| constant can thus enhance readability.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another benefit of constants, is that they can be used multiple times in the |
| same model:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int STEP = 2; |
| const int TARGET = 100; |
| |
| automaton movement: |
| disc int position = 0; |
| event forward, backward; |
| |
| location: |
| initial; |
| edge forward when position < TARGET do position := position + STEP; |
| edge backward when position > 0 do position := position - STEP; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this modified example it is possible for the object to perform <code>forward</code> |
| as well as <code>backward</code> movements. The step size is the same for both |
| movements, making it possible to use the <code>STEP</code> constant in the updates of |
| both edges. Since a constant is used, the speed of both movements can be |
| changed by changing the value of the constant. Without using a constant, the |
| speed would have to be changed separately for each edge.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Constants are not limited to integer values. Consider the following example, |
| where a more complex value is used:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum ProductType = A, B, C; |
| const dict(ProductType:real) DURATION = {A: 3.5, B: 5.7, C: 0.8};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This example declares a <code>ProductType</code> enumeration, with three different |
| product types: <code>A</code>, <code>B</code>, and <code>C</code>. The <code>DURATION</code> constant indicates |
| for each product type, how long it takes to produce a product of that type. |
| Products of type <code>A</code> can be produced in 3.5 hours, products of type <code>B</code> |
| in 5.7 hours, etc. To get the production duration of products of type <code>C</code>, |
| <a href="#tut-values-chapter-types-values-exprs">expression</a> <code>DURATION[C]</code> can be |
| used. For more information, see the lessons on |
| <a href="#tut-values-chapter-enumerations">enumerations</a> and |
| <a href="#tut-values-chapter-dictionaries">dictionaries</a>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse1-chapter-algebraic-variables">Algebraic variables</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Consider a conveyor belt with a product on it:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/reuse1/conveyor.png" alt="conveyor"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The product starts at the left side, at position <code>0</code>. There is a sensor that |
| can detect the product between positions <code>13</code> and <code>14</code>. The product exits |
| the conveyor at position <code>18</code>. The following CIF specification models the |
| conveyor, product, and sensor:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton conveyor: |
| disc real position = 0.0; |
| event move; |
| |
| const real width = 6; |
| alg bool sensor = position + width >= 13 and position <= 14; |
| |
| location: |
| initial; |
| edge move when position < 18 do position := position + 0.1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>conveyor</code> automaton models the conveyor, with a product on it. The |
| product is modeled by means of the <code>position</code> of the left side of the |
| product, relative to the left side of the conveyor. As the conveyor starts to |
| <code>move</code>, the product moves as well, and its position on the conveyor is |
| updated. The product moves in steps of <code>0.1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>width</code> of the product is <code>6</code>. The sensor is on whenever |
| the product, which spans from <code>position</code> to <code>position + width</code>, is within |
| the sensor range, which spans from <code>13</code> to <code>14</code>. An <em>algebraic variable</em> |
| named <code>sensor</code> is used here, to represent the value of the sensor.</p> |
| </div> |
| <div class="paragraph"> |
| <p>An algebraic variable is a variable whose value is determined by its |
| definition. For the <code>sensor</code> variable, its value is determined from a |
| calculation involving variable <code>position</code> and constant <code>width</code>. Unlike |
| discrete variables, algebraic variables can not be assigned a new value. The |
| value of algebraic variable <code>sensor</code> changes automatically as the value of |
| discrete variable <code>position</code> changes. The value of algebraic variable |
| <code>sensor</code> is <code>true</code> whenever the product is over the sensor, and it is |
| <code>false</code> otherwise.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If we had modeled the value of the sensor as a discrete variable, we would have |
| had to update the variable for every edge where the value of variable |
| <code>position</code> is updated. In this example, that is only one edge. However, if |
| the variable would have been updated on multiple edges, the sensor value would |
| also have to be updated for all those edges. Furthermore, when adding |
| another edge that updates the <code>position</code> variable, the edge needs to be |
| adapted to also update the <code>sensor</code> discrete variable, which can easily be |
| forgotten. Using an algebraic variable, the value computation needs to be |
| specified only once, and no changes to its value are needed, as the value |
| always remains consistent with its definition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic variables can be used to give an |
| <a href="#tut-values-chapter-types-values-exprs">expression</a> (computations) a name, |
| similar to how <a href="#tut-reuse1-chapter-constants">constants</a> can be used to |
| give fixed values a name. The benefits of using an algebraic variable are |
| similar to the benefits of using constants. Both can be used to improve |
| readability, and to make it easier to consistently change the model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic variables can also be used as an abstraction. Consider the following |
| extension of the specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton light: |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on when conveyor.sensor goto on; |
| |
| location on: |
| edge turn_off when not conveyor.sensor goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The idea is to have a light turn on when a product is detected by the sensor, |
| and have it turn off when the sensor no longer detects the product. The |
| algebraic variable <code>sensor</code> is used in the guard conditions of the <code>light</code> |
| automaton, to determine when the light should be turned on or off.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the example, the <code>light</code> automaton only uses the <code>sensor</code> variable from |
| automaton <code>conveyor</code>. It does not matter how the value of that variable is |
| defined. Currently, it is defined in terms of variable <code>position</code> and |
| constant <code>width</code>. However, if the <code>conveyor</code> automaton were modeled |
| differently, the expression that defines the value of the algebraic variable |
| could be changed, without the need to change the use of the variable in |
| automaton <code>light</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse1-chapter-algvar-equations">Algebraic variables and equations</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton car: |
| event start, stop, breakdown, start_repair, repaired; |
| |
| alg bool can_drive = idle or moving; |
| |
| location idle: |
| initial; |
| edge start goto moving; |
| |
| location moving: |
| edge stop goto idle; |
| edge breakdown goto broken; |
| |
| location broken: |
| edge start_repair goto repairing; |
| |
| location repairing: |
| edge repaired goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>car</code> is initially <code>idle</code>. Once you <code>start</code> driving, the car is |
| <code>moving</code>. Once you <code>stop</code> driving, the car is <code>idle</code> again. While |
| <code>moving</code> it is possible for a <code>breakdown</code> to occur, meaning the car is |
| <code>broken</code>. Once a mechanic starts the repair (<code>start_repair</code>), the mechanic |
| is <code>repairing</code> the car. Once it is <code>repaired</code>, the car is <code>idle</code>, and you |
| can <code>start</code> driving it again, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic variable <code>can_drive</code> indicates whether you can currently drive the |
| car. As the value calculation indicates, the car can be driven whenever it is |
| <code>idle</code> or <code>moving</code>. That is, it can’t be driven if the car is <code>broken</code> |
| or a mechanic is <code>repairing</code> it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the example above, the value of the algebraic variable is defined with the |
| declaration, as was already explained in the lesson that introduced |
| <a href="#tut-reuse1-chapter-algebraic-variables">algebraic variables</a>. However, it |
| also possible to specify the value separately, using an equation:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton car: |
| event start, stop, breakdown, start_repair, repaired; |
| |
| alg bool can_drive; |
| |
| equation can_drive = idle or moving; |
| |
| // Locations omitted for brevity. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This allows for separation of variable declarations and equations. Both |
| variants have the same algebraic variable with the same value. An equation of |
| an algebraic variable must be placed in the same component as where the |
| algebraic variable is declared. In the example above, the equation for |
| algebraic variable <code>can_drive</code> must be placed in automaton <code>car</code>, as that |
| is where the algebraic variable is declared.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For algebraic variables declared in automata, it is also possible to specify |
| the value using an equation per location of the automaton:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton car: |
| event start, stop, breakdown, start_repair, repaired; |
| |
| alg bool can_drive; |
| |
| location idle: |
| initial; |
| equation can_drive = true; |
| |
| edge start goto moving; |
| |
| location moving: |
| equation can_drive = true; |
| |
| edge stop goto idle; |
| edge breakdown goto broken; |
| |
| location broken: |
| equation can_drive = false; |
| |
| edge start_repair goto repairing; |
| |
| location repairing: |
| equation can_drive = false; |
| |
| edge repaired goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Every algebraic variable must have a unique value in every situation. Algebraic |
| variables must thus have a value with their declaration, a single equation in |
| the same component, or an equation in every location of the automaton. For |
| every algebraic variable, one of the three variants must be chosen. It is |
| allowed to choose a different variant for different algebraic variables, but it |
| is not allowed to use multiple variants for the same algebraic variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Which variant fits best for a specific algebraic variable, depends on the |
| situation. One of the benefits of using an equation per location, is |
| that the equations are checked for completeness. If you add a new location, you |
| must add an equation to that location as well, as otherwise the model is |
| invalid (incomplete). This means you can’t forget to specify the value of the |
| algebraic variable for that new location. If you use a value with the |
| declaration or a single equation in the component, you might forget to update |
| the value for the changes you made to the automaton.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse1-chapter-type-declarations">Type declarations</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Consider this slightly modified version of an example from the lesson on |
| <a href="#tut-reuse1-chapter-constants">constants</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum ProductType = A, B, C; |
| |
| const dict(ProductType:real) M1_DURATION = {A: 3.5, B: 5.7, C: 0.8}; |
| const dict(ProductType:real) M2_DURATION = {A: 1.8, B: 4.2, C: 3.9};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This example declares a <code>ProductType</code> enumeration, with three different |
| product types: <code>A</code>, <code>B</code>, and <code>C</code>. The <code>M1_DURATION</code> constant indicates |
| for each product type, how long it takes to produce a product of that type, |
| on machine 1. Products of type <code>A</code> can be produced in 3.5 hours, products of |
| type <code>B</code> in 5.7 hours, etc. Constant <code>M2_DURATION</code> is similar, but for |
| machine 2.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The type of both constants is the same. To avoid having to repeat complex types |
| in multiple places, a <em>type declaration</em> can be used:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum ProductType = A, B, C; |
| type Durations = dict(ProductType:real) |
| |
| const Durations M1_DURATION = {A: 3.5, B: 5.7, C: 0.8}; |
| const Durations M2_DURATION = {A: 1.8, B: 4.2, C: 3.9};</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>A type declaration with name <code>Durations</code> is introduced, and <code>Durations</code> can |
| then be used wherever a type is expected, instead of |
| <code>dict(ProductType:real)</code>. In the example above, <code>Durations</code> is used as |
| type of the two constants. The original specification and the one with the |
| type declaration have the same constants, with effectively the same type. That |
| is, in both specification the value of constant <code>M1_DURATION</code> is a |
| <a href="#tut-values-chapter-dictionaries">dictionary</a> with three key/value pairs.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Type declarations can be used to give a type a name, similar to how |
| <a href="#tut-reuse1-chapter-constants">constants</a> can be used to give fixed values |
| a name, and <a href="#tut-reuse1-chapter-algebraic-variables">algebraic variables</a> |
| can be used to give computations a name. The benefits are also similar, as type |
| declarations can be used to make specifications more concise, to increase |
| readability, and to make it easier to consistently change types throughout the |
| specification.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-time">Time</h3> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-intro">Timing</h4> |
| <div class="paragraph"> |
| <p> |
| |
| So far, the tutorial has only used discrete event models as examples, which are |
| all untimed. This lesson introduces the concept of timing.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In CIF, time starts at zero (<code>0.0</code>). Time can progress continuously. That is, |
| after one unit of time has passed, the model time is <code>1.0</code>. After an |
| additional one and a half time units have passed, the model time is <code>2.5</code>, |
| etc. By default, one time unit corresponds to one second. However, you can |
| decide to use another unit, and tools such as the simulator can be configured |
| to speed up or slow down the simulation accordingly.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-variable-time">Variable <code>time</code></h5> |
| <div class="paragraph"> |
| <p>A variable named <code>time</code> is always available in every specification. The |
| variable holds the current absolute model time as its value, and can be used |
| throughout the model. Initially, time and thus the value of variable <code>time</code> |
| start at zero (<code>0.0</code>). As time progresses, the value of variable <code>time</code> is |
| automatically updated to ensure it properly represents the current time of the |
| system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In this lesson, absolute time will be used. In most models, it is easier to use |
| relative time. This can be achieved with |
| <a href="#tut-time-chapter-continuous-variables">continuous variables</a>, discussed in |
| the next lesson.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-timed-guards">Timed guards</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event push, release; |
| |
| automaton user: |
| location start1: |
| initial; |
| edge push when time >= 1.5 goto stop1; |
| |
| location stop1: |
| edge release when time >= 2.3 goto start2; |
| |
| location start2: |
| edge push when time >= 2.4 goto stop2; |
| |
| location stop2: |
| edge release when time >= 7.6 goto done; |
| |
| location done; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>push</code> and <code>release</code> events represent pushing and releasing of a button |
| respectively. The actual behavior of the button itself is omitted. The |
| specification does model the behavior of a <code>user</code>. Initially, the <code>user</code> |
| is in location <code>start1</code>, and no time has passed. The edge with the <code>push</code> |
| event is not yet enabled, as the guard is not satisfied. As soon as one and a |
| half time units have passed, the guard condition becomes satisfied, and the |
| <code>push</code> event becomes enabled. This edge models that the user starts to push |
| the button after <code>1.5</code> time units. The user then waits for another <code>0.8</code> |
| (<code>2.3</code> - <code>1.5</code>) time units, before releasing the button (stop pushing it). |
| After waiting another <code>0.1</code> (<code>2.4</code> - <code>2.3</code>) time unit, the user pushes |
| the button again. Finally, after waiting <code>5.2</code> (<code>7.6</code> - <code>2.4</code>) time |
| units, the user releases the button one last time. In the <code>done</code> location, |
| the <code>push</code> and <code>release</code> events are never enabled (no edges for those |
| events), and thus the user never pushes or releases the button again. No other |
| events are enabled, so time keeps progressing forever, without any events |
| happening.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-time-transitions">Time transitions</h5> |
| <div class="paragraph"> |
| <p>The state space of the above specification is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/user_state_space.png" alt="user state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the names of the current locations of automaton |
| <code>user</code> and the current values of variable <code>time</code>. The transitions labeled |
| with event names are <em>event transitions</em>. The other transitions are |
| <em>time transitions</em>, which are labeled with the duration of the time |
| transitions, i.e. the number of time units that passes. At the end of the |
| state space, a time transition of infinite duration is shown, to indicate that |
| time can progress forever.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The current locations of automata can not change as time passes as the result |
| of taking a time transition. The only way for the current locations to change, |
| is as the result of taking an edge as part of an event transition.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-urgency">Urgency</h5> |
| <div class="paragraph"> |
| <p>By default, all events in CIF are <em>urgent</em>. Events being urgent means that |
| edges are taken as soon as possible. In other words, event transitions take |
| priority over time transitions. Time can only progress if no event transitions |
| are possible. For further details on urgency, see the future |
| <a href="#tut-time-chapter-urgency">urgency</a> lesson.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-numeric-time">Numeric time</h5> |
| <div class="paragraph"> |
| <p>In the above example, guard <code>time >= 1.5</code> is used. You might wonder why the |
| guard is not <code>time = 1.5</code>, as the intention is that user pushes the button |
| after exactly <code>1.5</code> time units, and not after <code>1.6</code> or <code>1.7</code> time units. |
| The main reason is that the <a href="#tools-cifsim-chapter-index">simulator</a> uses finite |
| precision in its numeric calculations to find the moment in time that the edge |
| becomes enabled. The answer also has finite precision. It is often not exactly |
| at <code>1.5</code> time units, but is slightly after it, say at time |
| <code>1.50000000000001</code>. If you use <code>time = 1.5</code> as guard instead of |
| <code>time >= 1.5</code>, the simulator will most likely |
| <a href="#tools-cifsim-solver-chapter-root-problems">miss the change</a> in enabledness of |
| the edge, and will never enable the event.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-continuous-variables">Continuous variables</h4> |
| <div class="paragraph"> |
| <p> |
| |
| In the lesson that introduced <a href="#tut-time-chapter-intro">timing</a>, variable |
| <code>time</code> was used. Variable <code>time</code> uses absolute model time, i.e. |
| the total amount of time that has passed since the start of the simulation. |
| It is usually easier to use relative model time, i.e. a certain amount of time |
| passes after a certain event. This is where <em>continuous variables</em> are ideal. |
| A continuous variable is a variable that changes value automatically, as time |
| progresses. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine: |
| event start, finished; |
| cont t = 0 der 1; |
| |
| location idle: |
| initial; |
| edge start do t := 0 goto producing; |
| |
| location producing: |
| edge finished when t >= 3 goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models a <code>machine</code> that is initially <code>idle</code>. The machine |
| can <code>start</code> to produce a product. After a while, it is done <code>producing</code>. |
| Due to having <code>finished</code> the product, it becomes <code>idle</code> again, until it is |
| starts to product the next product.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div id="lang-tut-time-continuous-variables-deriv" class="paragraph"> |
| <p>Continuous variable <code>t</code> is declared to initially have value <code>0</code>. Its |
| <em>derivative</em> is <code>1</code>, meaning that every unit of time that passes, the value |
| of <code>t</code> increases by <code>1</code>. Every time the <code>start</code> event happens, the value |
| of continuous variable <code>t</code> is reset to <code>0</code> using an assignment. As a result |
| of this reset, <code>t</code> will be <code>0</code> when the automaton enters the <code>producing</code> |
| location. The edge for the <code>finished</code> event indicates that the event can only |
| happen when <code>t >= 3</code> holds. This condition will hold after three time units. |
| This means that automaton <code>machine</code> remains in the <code>producing</code> location for |
| three time units, before going to the <code>idle</code> location. It will thus always |
| take three units after entering the <code>producing</code> location, before the guard |
| becomes enabled, and the <code>finished</code> event can take place. The state space is |
| as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/machine_state_space.png" alt="machine state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the first letters of the names of the current |
| locations of automaton <code>machine</code> and the current values of variables <code>time</code> |
| and <code>t</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Continuous variables always have <a href="#tut-values-chapter-reals">real</a> values. |
| Similar to discrete variables, if their initial value is not specified, it is |
| <code>0.0</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont t der 1; // Initial value is 0.0.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The derivative of a continuous variable can be used as a variable as well. The |
| derivative of continuous variable <code>t</code> is <code>t'</code>. A derivative is read only; |
| it can not be assigned. Similar to algebraic variables, it is always equal to |
| its definition. In the case of variable <code>t</code>, its derivative is always <code>1</code>. |
| The values of variables <code>time</code>, <code>t</code>, and <code>t'</code> as time progresses are:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/machine_plot.png" alt="machine plot"> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-contvar-equations">Continuous variables and equations</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton person: |
| event turn; |
| cont t = 0 der 1; |
| |
| location: |
| initial; |
| edge turn when t > 10 do t := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models a <code>person</code> walking back and forth. Every time that |
| the person has walked <code>10</code> time units, (s)he will <code>turn</code> around, walking |
| in the other direction.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the example above, the derivative of the continuous variable is defined with |
| the declaration, as was already explained in the lesson that introduced |
| <a href="#tut-time-chapter-continuous-variables">continuous variables</a>. However, it |
| also possible to specify the derivative separately, using an equation:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton person: |
| event turn; |
| cont t = 0; // Declaration specifies only the initial value. |
| |
| equation t' = 1; // Derivative specified using separate equation. |
| |
| location: |
| initial; |
| edge turn when t > 10 do t := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This allows for separation of variable declarations and equations. Both |
| variants have the same continuous variable with the same derivative. An |
| equation of a derivative of a continuous variable must be placed in the same |
| component as where the continuous variable is declared. In the example above, |
| the equation for <code>t'</code> must be placed in automaton <code>person</code>, as that is |
| where <code>t</code> is declared.</p> |
| </div> |
| <div class="paragraph"> |
| <p>We could extend this specification to keep track of the direction that the |
| person is moving:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton person: |
| event turn; |
| cont t = 0 der 1; |
| |
| location away: |
| initial; |
| edge turn when t > 10 do t := 0.0 goto back; |
| |
| location back: |
| edge turn when t > 10 do t := 0.0 goto away; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For continuous variables declared in automata, it is also possible to specify |
| the derivative using an equation per location of the automaton. This allows us |
| to keep track of the exact position of the person:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton person: |
| event turn; |
| cont pos = 0; |
| |
| location away: |
| initial; |
| equation pos' = 1; |
| edge turn when pos > 10 goto back; |
| |
| location back: |
| equation pos' = -2; |
| edge turn when pos < 0 goto away; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the continuous variable <code>t</code> has been renamed to <code>pos</code>, to make it |
| more clear that it indicates the position of the person. As long as the |
| person is moving <code>away</code>, the derivative of <code>pos</code> is <code>1</code>, and the |
| person moves away, one place every time unit. When the person reaches |
| position <code>10</code>, the position is not reset to zero. Instead, only the location |
| is changed to the <code>back</code> location. In that location, the derivative of |
| <code>pos</code> is <code>-2</code>. This means that every time unit, the position decreases |
| by <code>2</code>. That is, the person back to the original position, but at twice the |
| speed. The values of variables <code>time</code>, <code>pos</code>, and <code>pos'</code> as time |
| progresses are:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/person_plot.png" alt="person plot"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As with <a href="#tut-reuse1-chapter-algvar-equations">algebraic variables</a>, every |
| continuous variable must have a unique derivative in every situation. |
| Continuous variables must thus have a derivative with their declaration, a |
| single equation in the same component, or an equation in every location of the |
| automaton. For every continuous variable, one of the three variants must be |
| chosen. It is allowed to choose a different variant for different continuous |
| variables, but it is not allowed to use multiple variants for the same |
| continuous variable.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-equations">Equations</h4> |
| <div class="paragraph"> |
| <p> |
| Consider the following |
| <a href="http://en.wikipedia.org/wiki/Nonlinear_system">non-linear system</a>:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/tank.png" alt="tank"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>V</code> models the water volume of a tank. The water volume of the tank |
| changes based on the incoming flow of water <code>Qi</code> and outgoing flow of water |
| <code>Qo</code>. The tank can be modeled using the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont V = 5 der Qi - Qo; |
| alg real Qi = 1; |
| alg real Qo = sqrt(V);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Initially, the tank is filled with <code>5</code> liters of water. The incoming flow is |
| constant at <code>1</code> liter per second. The outgoing flow increases as the water |
| volume of the tank increases.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By separating the declarations of the three variables from their equations, the |
| specification becomes more readable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont V = 5; |
| alg real Qi; |
| alg real Qo; |
| |
| equation V' = Qi - Qo; |
| equation Qi = 1; |
| equation Qo = sqrt(V);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The values of the variables as time passes are shown in the following figure:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/tank_plot.png" alt="tank plot"> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-var-overview">Variables overview</h4> |
| <div class="paragraph"> |
| <p> |
| |
| CIF features different kinds of variables, that have different functionality. |
| Each is better suited for a particular purpose. The following table gives an |
| overview:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3334%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Kind of variable</th> |
| <th class="tableblock halign-center valign-top">Can be assigned</th> |
| <th class="tableblock halign-center valign-top">Can change as time progresses</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tut-data-chapter-discrete-variables">Discrete variable</a></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock"><strong>yes</strong></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tut-reuse1-chapter-algebraic-variables">Algebraic variable</a></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock"><strong>yes</strong></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tut-time-chapter-continuous-variables">Continuous variable</a></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock"><strong>yes</strong></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock"><strong>yes</strong></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#lang-tut-time-continuous-variables-deriv">Derivative of a continuous variable</a></p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-center valign-top"><p class="tableblock"><strong>yes</strong></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Discrete variables can only change value when given an explicit new value by |
| means of an assignment. They don’t change automatically as time progresses.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic variables can’t be assigned. Instead, their values depend on their |
| declarations or equation(s). If the computations that result in their values |
| depend on a variable that can change value as time progresses, then so can |
| the values of the algebraic variables. Algebraic variables are used as named |
| shorthand notations for computations, for readability, reuse, consistency, and |
| abstraction.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Continuous variables automatically change value as time progresses, as |
| specified by their derivatives. They can also be assigned new values, from |
| which they then automatically change again, based on the current values of |
| their derivatives.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The derivatives of the continuous variables can be seen as variables |
| themselves. Their values depend on their declaration or equation(s). If the |
| computations that result in their values depend on a variable that can change |
| value as time progresses, then so can the values of the derivatives.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-urgency">Urgency</h4> |
| <div class="paragraph"> |
| <p> |
| In CIF, urgency indicates whether or not time may progress. CIF has three forms |
| of urgency: event urgency, location urgency, and edge urgency. Edge urgency |
| should be avoided, and is not explained here.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-event-urgency">Event urgency</h5> |
| <div class="paragraph"> |
| <p>By default, all events in CIF are <em>urgent</em>. Events being urgent means that |
| edges are taken as soon as possible. In other words, event transitions take |
| priority over time transitions. Time can only progress if no event transitions |
| are possible. It is not possible to make events non-urgent in a CIF model, but |
| specific tools may allow making events non-urgent.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-time-urgloc">Location urgency</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton use_case: |
| location first: |
| initial; |
| edge tau goto second; |
| |
| location second: |
| edge tau goto done; |
| |
| location done; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This automaton represents a use case, which goes from one location to the next. |
| The state space is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/usecase_nonurg_state_space.png" alt="usecase nonurg state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The states are labeled with the names of the current locations of automaton |
| <code>use_case</code> and the current values of variable time. At the end of the use |
| case, no events are possible, and thus time can progress infinitely. To force |
| that in location <code>done</code> no time can progress, the location can be made |
| urgent:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton use_case: |
| location first: |
| initial; |
| edge tau goto second; |
| |
| location second: |
| edge tau goto done; |
| |
| location done: |
| urgent; // Location is now urgent. |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting state space is:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/time/usecase_urgloc_state_space.png" alt="usecase urgloc state space"> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-time-chapter-deadlock-livelock">Deadlock and livelock</h4> |
| <div class="paragraph"> |
| <p>This lesson explains the concepts of deadlock and livelock.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-time-deadlock">Deadlock</h5> |
| <div class="paragraph"> |
| <p>If no event transitions are possible, and also no time transitions are possible |
| (time may not progress), then no transitions are possible. This is called |
| <em>deadlock</em>. No behavior is possible, or will ever become possible. As an |
| example, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton use_case: |
| location wait3: |
| initial; |
| urgent; |
| edge tau when time > 3 goto done; |
| |
| location done; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Location <code>wait3</code> is the initial location. Initially, <code>time</code> is zero. Time |
| can not progress, as the location is <a href="#lang-tut-time-urgloc">urgent</a>. |
| Since the guard of the edge also does not hold, event <code>tau</code> is also not |
| possible. No transitions are possible, and the specification is in deadlock.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-time-livelock">Livelock</h5> |
| <div class="paragraph"> |
| <p>As long as an event is possible, no time may pass. If by mistake always an |
| event is possible, this prevents all passage of time. Consider the following |
| CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton car: |
| event increase, decrease, arrived; |
| disc real speed = 0; |
| cont pos der speed; |
| |
| location underway: |
| initial; |
| edge increase when speed < 100 do speed := speed + 1; |
| edge decrease when speed > 0 do speed := speed - 1; |
| edge arrived when pos = 850 goto done; |
| |
| location done; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models a <code>car</code> that can <code>increase</code> and <code>decrease</code> its |
| speed, so that it is at least <code>0</code> and at most <code>100</code>. It keeps track of its |
| position (continuous variable <code>pos</code>) that increases more quickly as the speed |
| increases. When position <code>850</code> is reached, the car has <code>arrived</code> and is |
| <code>done</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The car will be increasing and decreasing it speed, using the <code>increase</code> and |
| <code>decrease</code> events. As always at least one of them is enabled at any moment, |
| time can never progress, and <code>pos</code> remains zero. This effect is called |
| <em>livelock</em>. While behavior is still possible, the model does not truly progress |
| with useful behavior. The model gets 'stuck' repeating one or a few events.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-channel-communication">Channel communication</h3> |
| <div class="sect3"> |
| <h4 id="tut-channels-chapter-intro">Channels</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Consider the following figure of a producer and two consumers, where rectangles |
| represent entities and the arrows represent the data that is communicated:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/channels/producer_consumer.png" alt="producer consumer"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The producer creates products, identified by a unique identification |
| number. Each product produced by the producer, is provided either to |
| the first or to the second consumer. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event provide1, provide2; |
| |
| automaton producer: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide1, provide2 do nr := nr + 1; |
| end |
| |
| automaton consumer1: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide1 do nr := producer.nr; |
| end |
| |
| automaton consumer2: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide2 do nr := producer.nr; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>producer</code> keeps track of the identification number (variable <code>nr</code>) of |
| the current product, and provides products to either the first consumer |
| (event <code>provide1</code>) or the second consumer (<code>provide2</code>). Both consumers |
| have an identification number of their current product as well (variable |
| <code>nr</code> in the consumer automata). Initially, the consumers don’t have a |
| product, as indicated by value <code>-1</code>. When a consumer gets a new product, it |
| looks up the identification number of the product at the producer, and stores |
| it locally. The producer then moves on to the next product, by increasing its |
| current identification number.</p> |
| </div> |
| <div class="paragraph"> |
| <p>We can identify two problems in this model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first problem is that we need two events in order for the producer to |
| provide products to <em>either</em> the one consumer <em>or</em> the other consumer. If we |
| used only one event, both consumers would need to use that event, have the |
| event in their <a href="#tut-basics-chapter-alphabet">alphabet</a>, and would thus have |
| to simultaneously participate in the |
| <a href="#tut-basics-chapter-synchronizing-events">synchronization</a>. A consequence of |
| having an event per consumer, is that the <code>producer</code> automaton has both |
| events on its edge. Adding a third consumer entails having to add another |
| event, as well as having to modify the edge of the <code>producer</code> automaton. This |
| is not a nice scalable solution.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second problem is that the consumer refers directly to the <code>nr</code> variable |
| of the <code>producer</code> automaton. This introduces a very tight coupling between |
| the producer and the consumers. It exposes the <code>nr</code> variable of the |
| <code>producer</code> to the consumers, making it more difficult to change the producer |
| without changing the consumers.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Both these problems can be solved by using <em>channels</em>. Channels are a special |
| form of events, that can be used to communicate or transmit data from a |
| <em>sender</em> to a <em>receiver</em>. In our example, data that is communicated are the |
| identification numbers of the products, the producer is the sender, and the |
| consumers are the receivers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Channels require one or more potential senders, and one or more potential |
| receivers. Automata cannot be both sender and receiver for a single channel. |
| They may however be a sender for one channel, and a receiver for another |
| channel. For every transition, exactly one of the senders and exactly one of |
| the receivers participate. The sender sends a value, and the receiver |
| receives that value. This type of communication is often called channel |
| communication or <em>point-to-point</em> communication, as the data is communicated |
| from one point (the sender) to another point (the receiver).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Multiple automata that synchronize over the same event perform a transition |
| together. Similarly, a sender and receiver that together perform a |
| channel communication, perform a transition together. In both cases, |
| all automata involved take their respective edges <em>synchronously</em> |
| (simultaneously).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Channels are ideally suited for modeling product flows, or more generally the |
| movement of physical entities through a system. Physical objects usually don’t |
| duplicate themselves or spontaneously stop to exist. This fits nicely with |
| channels, where data is communicated or passed along from exactly one sender |
| to one receiver. In our example, product produced by the producer are |
| physically provided to one of the consumers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following CIF specification models the above example using channels:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int provide; |
| |
| automaton producer: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton consumer1: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end |
| |
| automaton consumer2: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The <code>provide1</code> and <code>provide2</code> events have been replaced by a single |
| channel named <code>provide</code>. Channels are declared similar to events, but have a |
| <a href="#tut-values-chapter-types-values-exprs">data type</a> that indicates the type |
| of <a href="#tut-values-chapter-types-values-exprs">values</a> that are communicated |
| over the channel. In this case <a href="#tut-values-chapter-integers">integers</a> are |
| communicated.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The <code>producer</code> now uses the channel on its edge, instead of the two events. |
| The exclamation mark (<code>!</code>) after the channel name means that the producer |
| is sending over the channel. After the exclamation mark, the value that the |
| producer sends is given. In this case, the producer sends the identification |
| number of its current product.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The edges of the consumers have been modified as well. The channel is used |
| with a question mark (<code>?</code>) after the channel name, indicating that the |
| consumers receive over the channel. The received value, which is available as |
| the <code>?</code> variable in the update, is directly assigned to the <code>nr</code> variable |
| of the consumer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By using channels, we no longer need multiple events, and the producer does not |
| need to be modified if another consumer is added. This makes the model scalable |
| to varying amount of consumers. Furthermore, the consumers now use the <code>?</code> |
| variable to obtain the received value, and no longer need direct access to the |
| variables of the producer. This makes it easier to modify the producer |
| without having to also modify the consumers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To conclude this lesson, we’ll extend the example with a second producer:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int provide; |
| |
| automaton producer1: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton producer2: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton consumer1: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end |
| |
| automaton consumer2: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>producer</code> automaton has been renamed to <code>producer1</code>, and a |
| <code>producer2</code> has been added. Both producers independently produce products |
| and provide them to the consumers. Both consumers can receive products from |
| either producer. At all times, four transitions are possible: |
| <code>producer1</code> communicates with <code>consumer1</code>, <code>producer1</code> communicates with |
| <code>consumer2</code>, <code>producer2</code> communicates with <code>consumer1</code>, or <code>producer2</code> |
| communicates with <code>consumer2</code>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-channels-chapter-void">Dataless channels</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| Besides channels that communicate data, it is also possible to use dataless |
| channels. A channel that does not communicate any data, is declared with the |
| <code>void</code> type. Dataless channels are also called <code>void</code> channels. When using |
| dataless channels, the sender does not provide a value to send over the |
| channel. Also, the receiver cannot use the received value (variable <code>?</code>) |
| since no data is communicated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Dataless channels are used in the same situations as 'normal' channels, |
| for instance when physical product flow is modeled. If products don’t |
| have an identification number, and can not be distinguished based on color or |
| some other property, all products are essentially equal. It is then sufficient |
| to communicate that a product is being 'transferred'. No further data is |
| needed. While it is possible to communicate dummy values, dataless channels |
| provide a better solution in such cases.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider again the producer/consumer example from the |
| <a href="#tut-channels-chapter-intro">previous lesson</a>, with one producer and two |
| consumers, but without identification numbers for the products:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event void provide; |
| |
| automaton producer: |
| location: |
| initial; |
| edge provide!; |
| end |
| |
| automaton consumer1: |
| location: |
| initial; |
| edge provide?; |
| end |
| |
| automaton consumer2: |
| location: |
| initial; |
| edge provide?; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>producer</code> still produces products and provides them to either the first |
| or the second consumer.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-channels-chapter-chan-sync-combi">Combining channel communication with event synchronization</h4> |
| <div class="paragraph"> |
| <p> |
| Consider again the producer/consumer example with two producers and two |
| consumers, from a <a href="#tut-channels-chapter-intro">previous lesson</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int provide; |
| |
| automaton producer1: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton producer2: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton consumer1: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end |
| |
| automaton consumer2: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Now assume we want to restrict communication to allow at most five products in |
| total to be provided to the consumers. We could adapt both producers, as |
| follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton producer1: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr when nr + producer2.nr < 5 do nr := nr + 1; |
| end |
| |
| automaton producer2: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr when producer1.nr + nr < 5 do nr := nr + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each producer gets an additional guard condition whether it may provide a |
| product to one of the consumers. If the total number of products provided by |
| both providers does not exceed five, they may still provide a product. Having |
| to adapt both producers is less than ideal.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an alternative solution, we can add an additional automaton, instead of |
| adapting the producers:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton controller: |
| disc int cnt = 0; |
| |
| location: |
| initial; |
| edge provide when cnt < 5 do cnt := cnt + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This <code>controller</code> automaton (together with the original producer automata) |
| keeps track of the number of products provided to consumers, by counting them |
| in variable <code>cnt</code>. It only allows the <code>provide</code> event when less than five |
| products have been provided. If five or more products have been provided, it |
| disables the <code>provide</code> event.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the <code>controller</code> automaton, the <code>provide</code> channel is used as an event |
| rather than a channel. When one of the producers and one of the consumers |
| together perform a channel communication, the <code>controller</code> automaton that has |
| the <code>provide</code> event in its <a href="#tut-basics-chapter-alphabet">alphabet</a>, must |
| synchronize with it. This allows the <code>controller</code> to impose additional |
| restrictions on the channel communication, allowing or forbidding it in |
| certain cases. The <code>controller</code> is added as a separate process, which |
| improves scalability.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, every automaton may either send over a channel, receive over a |
| channel, or synchronize with a channel. An automaton may not take on more than |
| one of these roles, for a single event. It may however send over one channel, |
| receive over another channel, and synchronize with yet another one.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Every event transition for a channel requires exactly one automaton that |
| participates as sender, and exactly one automaton that participates as |
| receiver. Furthermore, all automata that have the channel in their alphabet, |
| must additionally participate as well, by synchronizing together with the |
| sender and receiver. Automata that send or receive over a channel, do not have |
| that channel in their alphabet. Only automata that synchronize with an event |
| or channel have that event or channel in their alphabet.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Automata that synchronize over a channel can be used to further <em>restrict</em> the |
| allowed channel communications, as shown in the above example. It is however |
| also possible for the additional synchronizing automata to |
| <a href="#tut-data-chapter-monitoring">monitor</a> (observe) the channel communication.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-functions">Functions</h3> |
| <div class="sect3"> |
| <h4 id="tut-functions-chapter-intro">Functions</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Functions can be used to compute values from other values. CIF has many |
| built-in functions, called <em>standard library functions</em>. An example is the |
| <code>size</code> function, which takes a <a href="#tut-values-chapter-lists">list</a> and |
| returns the number of elements of the list. Another example is the <code>abs</code> |
| function, which takes an <a href="#tut-values-chapter-integers">integer</a> or |
| <a href="#tut-values-chapter-reals">real</a> number and computes the absolute value of |
| that number.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| While many built-in functions are available, they may not always suffice. |
| User-defined functions can be added to CIF models, to allow custom computations |
| needed by the model. By putting the calculation in a user-defined function, the |
| calculation can be used in several places, allowing for reuse. Furthermore, |
| functions allow for more complex computations than would otherwise be possible.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| CIF features two kinds of user-defined functions: internal ones and external |
| ones. Internal user-defined functions are fully defined within the CIF model. |
| External user-defined functions declare only a header which indicates the |
| existence of the function, while the actual implementation is obtained from an |
| external source. The lessons of this category only explain internal |
| user-defined functions. The language reference documentation gives more |
| information on external user-defined functions.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-functions-chapter-internal-functions">Internal user-defined functions</h4> |
| <div class="paragraph"> |
| <p> |
| The most commonly used <a href="#tut-functions-chapter-intro">kind</a> of user-defined |
| functions are the internal user-defined functions. Consider the following CIF |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func real mean(list real vs): |
| int length = size(vs); |
| int index = 0; |
| real sum = 0; |
| |
| while index < length: |
| sum := sum + vs[index]; |
| index := index + 1; |
| end |
| return sum / length; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| This specification defines a function (keyword <code>func</code>) named <code>mean</code>. After |
| the name of the function, between the parentheses, the <em>parameters</em> are listed. |
| The parameters are the input values, which the function can use to compute its |
| result. In this example, the function takes a |
| <a href="#tut-values-chapter-lists">list</a> of <a href="#tut-values-chapter-reals">real</a> |
| values as its only parameter. Parameter name <code>vs</code> can be used in the body of |
| the function to refer to this input value. Just after the <code>func</code> keyword, the |
| <a href="#tut-values-chapter-types-values-exprs">type</a> of the <em>result</em> of the |
| computation is specified. In this case, the function results in a |
| <a href="#tut-values-chapter-reals">real</a> typed value. The <code>mean</code> function takes a |
| list of integer values and produces a single real value as result.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| In the <em>body</em> of the function, local variables can be declared. The <code>mean</code> |
| function declares three variables: <code>length</code>, <code>index</code>, and <code>sum</code>. Local |
| variables of functions are very similar to |
| <a href="#tut-data-chapter-discrete-variables">discrete variables</a>. The main |
| difference is that they are |
| declared without the <code>disc</code> keyword. In the example, <code>length</code> is set to the |
| number of elements in list <code>vs</code>. Variables <code>index</code> and <code>sum</code> are both |
| initialized to <code>0</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| After the local variables (if any), the statements of the body are given. The |
| statements implement the algorithm, the actual computation of the function. |
| Statements are executed one after another, in the order they are given. In the |
| <code>mean</code> function, the <code>while</code> statement is executed before the <code>return</code> |
| statement. The <code>mean</code> function first calculates the sum of the input values, |
| and then <em>returns</em> the mean value. The details of the statements are discussed |
| in the <a href="#tut-functions-chapter-statements">next lesson</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| A function can be called (or applied) on concrete input values, to obtain the |
| computation result for those specific input values. For instance, consider the |
| following extension to the above CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg real m = mean([1.5, 3.2, 7.9, 15.8]); |
| |
| automaton a: |
| disc real x; |
| |
| location: |
| initial; |
| edge do x := 2 * mean([0.4, 1.5, 6.8]); |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic variable <code>m</code> is given the value that results from calling function |
| <code>mean</code> on a single <em>argument</em>, a list with four values. Each argument of a |
| function call must match with the corresponding parameter of the function being |
| called. In this case, the list of four real values matches with the <code>vs</code> |
| parameter of the <code>mean</code> function, which has type <code>list real</code>. Variable |
| <code>m</code> becomes <code>7.1</code>, as the mean of those four values is <code>7.1</code> |
| (<code>(1.5 + 3.2 + 7.9 + 15.8) / 4</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The edge in automaton <code>a</code> assigns a value to variable <code>x</code>. The mean of a |
| list of three values is calculated, and multiplied by two, to obtain the new |
| value of <code>x</code>. The mean of <code>0.4</code>, <code>1.5</code>, and <code>6.8</code> is |
| <code>(0.4 + 1.5 + 6.8) / 3</code>, which is <code>2.9</code>. Variable <code>x</code> gets <code>5.8</code> |
| (<code>2.9 * 2</code>) as its new value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Function <code>mean</code> is called in two places in the example, showing reuse of |
| calculations.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Functions in CIF are mathematical functions. That is, the result of a function |
| is the same for the same input values, and functions have no side effects. |
| Functions can not directly access variables outside their body. For example, |
| they cannot access discrete, continuous, and algebraic variables. They can also |
| not use variable <code>time</code>. To use the values of those variables in a function, |
| they have to to be passed in through parameters.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-functions-chapter-statements">Function statements</h4> |
| <div class="paragraph"> |
| <p> |
| This lesson explains the different statements that can be used in internal |
| user-defined functions:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-tut-functions-statements-assignment">Assignment statement</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions-statements-if">If statement</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions-statements-return">Return statement</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions-statements-while">While statement</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions-statements-break">Break statement</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-functions-statements-continue">Continue statement</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-assignment">Assignment statement</h5> |
| <div class="paragraph"> |
| <p>Assignments in functions are very similar to assignments to |
| <a href="#tut-data-chapter-discrete-variables">discrete variables</a>. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">x := x + 1;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Besides local variables, it also allowed to assign new values to the |
| parameters. Changes to parameters only have effect inside the function itself.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For <a href="#lang-tut-data-asgn-old-vs-new-multi">multi-assignments</a>, the |
| outer parentheses are not needed:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Multi-assignment on an edge. |
| edge do (x, y) := (1, 2); |
| |
| // Multi-assignment in a function. |
| x, y := 1, 2;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-if">If statement</h5> |
| <div class="paragraph"> |
| <p>It is possible to perform different calculations under different circumstances. |
| Consider the following function:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func int signum(real x): |
| if x > 0: |
| return 1; |
| elif x < 0: |
| return -1; |
| else |
| return 0; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This <code>signum</code> function takes a real number <code>x</code> and returns its |
| <a href="http://en.wikipedia.org/wiki/Signum_function">sign</a>. |
| The <code>if</code> statement |
| is used to detect the different situations, and to return the correct result |
| in each of those situations.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-return">Return statement</h5> |
| <div class="paragraph"> |
| <p>The execution of a function ends when a <code>return</code> statement is encountered. |
| The value following the <code>return</code> statement is the result of the entire |
| function. Consider again the <code>return</code> statement from the <code>mean</code> function |
| from the <a href="#tut-functions-chapter-internal-functions">previous lesson</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">return sum / length;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this case, the <code>sum</code> of the input values is divided by the number of input |
| elements (variable <code>length</code>) to obtain the mean of the input values. The mean |
| of the input values is the result of the function.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-while">While statement</h5> |
| <div class="paragraph"> |
| <p>The <code>while</code> statements allows for repeated execution of the statements in its |
| body, as long as the condition of the <code>while</code> loop holds. Consider again the |
| <code>mean</code> function from the |
| <a href="#tut-functions-chapter-internal-functions">previous lesson</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func real mean(list real vs): |
| int length = size(vs); |
| int index = 0; |
| real sum = 0; |
| |
| while index < length: |
| sum := sum + vs[index]; |
| index := index + 1; |
| end |
| return sum / length; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>mean</code> function processes each of its input values, using a <code>while</code> |
| loop. As long as the condition (<code>index < length</code>) holds, the body of the |
| <code>while</code> is executed over an over. The body consists of two assignments. The |
| first assignment obtains an input value (<code>vs[index]</code>) and adds it to the |
| <code>sum</code>. The second statement increases the index, to proceed with the next |
| input value. After the two assignments have been executed, the condition of the |
| <code>while</code> is evaluated again. If the condition still holds, the two assignments |
| are executed again, etc. When the condition no longer holds, the <code>while</code> |
| statement is done, and execution proceeds with the next statement, the |
| <code>return</code> statement.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-break">Break statement</h5> |
| <div class="paragraph"> |
| <p>A <code>break</code> statement 'jumps out' of a <code>while</code> statement, continuing with the |
| first statement after the <code>while</code>. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Get the first 'n' values from 'xs' that are not 'bad'. |
| func list int first_n(list int xs; int n; int bad): |
| int index = 0; |
| int x; |
| list int result = []; |
| |
| while index < size(xs): |
| x := xs[index]; |
| if x != bad: |
| result := result + [x]; |
| end |
| if size(result) = n: |
| break; |
| end |
| index := index + 1; |
| end |
| return result; |
| end |
| |
| // The value of 'y' is [1, 5, 3]. |
| alg list int y = first_n([1, 2, 5, 3, 4, 1, 3], 3, 2);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>first_n</code> function takes a list of integer numbers <code>xs</code>, and returns a |
| list <code>result</code> with the first <code>n</code> numbers from <code>xs</code> that are not <code>bad</code>. |
| A <code>while</code> loop is used to process each of the numbers in list <code>xs</code>. The |
| current number is stored in variable <code>x</code>. If the current number is not the |
| same as <code>bad</code>, it is added to the <code>result</code>. If the <code>result</code> then contains |
| <code>n</code> values, the <code>break</code> statement is used to break out of the <code>while</code> |
| loop and continue execution at the first statement after the <code>while</code> loop, |
| which is the <code>return</code> statement. If less than <code>n</code> values are in the result, |
| <code>index</code> is incremented to ensure the next number of the list is processed in |
| the next iteration of the <code>while</code> loop. The <code>return</code> statement at the end |
| of the function is used to return the <code>result</code> list, which contains at most |
| <code>n</code> values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-functions-statements-continue">Continue statement</h5> |
| <div class="paragraph"> |
| <p>A <code>continue</code> statement 'jumps over' the remaining statements in the body |
| of a <code>while</code> statement, and continues with the next iteration of that |
| <code>while</code> statement. Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Get the values from 'xs' that are greater than 5. |
| func list int filter_gt5(list int xs): |
| int index = 0; |
| int x; |
| list int result = []; |
| |
| while index < size(xs): |
| x := xs[index]; |
| index := index + 1; |
| if x <= 5: |
| continue; |
| end |
| result := result + [x]; |
| end |
| return result; |
| end |
| |
| // The value of 'y' is [8, 7, 6]. |
| alg list int y = filter_gt5([1, 8, 5, 7, 4, 6, 3]);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>filter_gt5</code> function takes a list of integer numbers, and returns a |
| filtered list that only contains those integer number that are greater than 5. |
| A <code>while</code> loop is used to process each of the numbers in list <code>xs</code>. The |
| current number is stored in variable <code>x</code>, and <code>index</code> is incremented to |
| ensure the next number of the list is processed in the next iteration of the |
| <code>while</code> loop. If the current number is not greater than 5, the remaining |
| statements in the body of the <code>while</code> are skipped, meaning <code>x</code> is not |
| added to the <code>result</code>. The <code>while</code> loop then continues with the next |
| iteration, for the next number in <code>xs</code>. If the current number (<code>x</code>) is |
| greater than 5, execution continues after the <code>if</code> statement, and the number |
| is added to the <code>result</code>. After all numbers in the list have been processed, |
| the filtered <code>result</code> list is returned to the caller of the function.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-functions-chapter-functions-as-values">Functions as values</h4> |
| <div class="paragraph"> |
| <p>Functions can be used as <a href="#tut-values-chapter-types-values-exprs">values</a>. |
| By treating them as data, they can be stored in variables, and passed to other |
| functions. This lesson shows one example of how that can be useful.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following list of numbers:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg list real nrs = [0.5, 1.3, 0.1, 2.7, 1.4];</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Now assume we wanted to sort these numbers both in increasing and in decreasing |
| order, using a single sorting function:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg list real inc = sort(nrs, cmp_inc); // [0.1, 0.5, 1.3, 1.4, 2.7] |
| alg list real dec = sort(nrs, cmp_dec); // [2.7, 1.4, 1.3, 0.5, 0.1]</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>inc</code> contains the same numbers as <code>nrs</code>, but sorted in increasing |
| order, while <code>dec</code> contains them in decreasing order. We use the same |
| <code>sort</code> function in both cases, but with different comparison functions:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func bool cmp_inc(real a, b): |
| return a <= b; |
| end |
| |
| func bool cmp_dec(real a, b): |
| return a >= b; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Function <code>cmp_inc</code> takes two real numbers and returns <code>true</code> only if the |
| first number is smaller than the second one (<code>a</code> and <code>b</code> are in increasing |
| order). Function <code>cmp_dec</code> has the same parameters, but returns <code>true</code> only |
| if the first number is larger than the second one (<code>a</code> and <code>b</code> are in |
| decreasing order). The <code>sort</code> function is defined as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func list real sort(list real xs; func bool (real, real) cmp): |
| int i = 1, j; |
| real x; |
| |
| while i < size(xs): |
| j := i; |
| while j > 0 and not cmp(xs[j-1], xs[j]): |
| // swap x[j-1] and x[j] |
| x := xs[j-1]; |
| xs[j-1] := xs[j]; |
| xs[j] := x; |
| j := j - 1; |
| end |
| i := i + 1; |
| end |
| return xs; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>sort</code> function has two parameters. The first parameter is <code>xs</code>, which |
| contains the values to sort. The second parameter is <code>cmp</code>, the compare |
| function to use to determine whether two numbers are correctly ordered. The |
| <code>cmp</code> parameter has type <code>func bool (real, real)</code>, which means that a |
| function that has two real parameters and a boolean return value is required. |
| The <code>cmp_inc</code> and <code>cmp_dec</code> functions satisfy these requirements, and can |
| be used as second argument when the function is called to determine the values |
| of algebraic variables <code>inc</code> and <code>dec</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>sort</code> function implements a standard |
| <a href="http://en.wikipedia.org/wiki/Insertion_sort">insertion sort</a> |
| algorithm. The |
| <code>cmp</code> parameter is used in the <code>sort</code> function to compare two consecutive |
| values in <code>xs</code>, and swap them if they are not correctly ordered.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>cmp</code> parameter of the <code>sort</code> function has a function type, allowing |
| compare functions to be passed to the <code>sort</code> function, as data. This allows |
| the <code>sort</code> function to sort lists of numbers in different orders, depending |
| on the compare function that is provided.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-scalable-solutions-and-reuse-22">Scalable solutions and reuse (2/2)</h3> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-aut-def-inst">Automaton definition/instantiation</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| Parts of a system that are nearly identical, are often modeled as nearly |
| identical automata. Having to specify them multiple times can be burdensome. |
| It can also hinder scalability, as changes to one of them usually need to be |
| applied to the others as well. Consider again the producer/consumer |
| example from the <a href="#tut-channels-chapter-intro">lesson that introduced channels</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int provide; |
| |
| automaton producer: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton consumer1: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end |
| |
| automaton consumer2: |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The producer provides products either to the first consumer or to the second |
| consumer. The consumers are modeled using identical automata. Only the names of |
| the <code>consumer1</code> and <code>consumer2</code> automata differ. Ideally, we would have a |
| sort of consumer template, and use that template twice, once for each of the |
| actual consumers. This can be achieved in CIF using an <em>automaton definition</em> |
| (the template) and two <em>automaton instantiations</em> (the uses of the template):</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int provide; |
| |
| automaton producer: |
| disc int nr = 0; |
| |
| location: |
| initial; |
| edge provide!nr do nr := nr + 1; |
| end |
| |
| automaton def Consumer(): |
| disc int nr = -1; |
| |
| location: |
| initial; |
| edge provide? do nr := ?; |
| end |
| |
| consumer1: Consumer(); |
| consumer2: Consumer();</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>Consumer</code> automaton definition is identical to the original consumers, |
| except that it is an automaton definition rather than an automaton. An |
| automaton definition can be identified by the <code>def</code> keyword between the |
| <code>automaton</code> keyword and the name of the automaton definition, as well as by |
| the parentheses after its name. As a convention, names of automaton definitions |
| start with an upper case letter (<code>Consumer</code> rather than <code>consumer</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>An automaton definition by itself is not an automaton. The instantiations of |
| the automaton definition (<code>consumer1</code> and <code>consumer2</code>) however, <em>are</em> |
| automata. Before the colon (<code>:</code>), the name of the instantiation is given. |
| This name is also the name of the actual automaton. After the colon, the name |
| of the automaton definition that is instantiated is given.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using an automaton definition, the above example models the behavior of a |
| consumer only once. Adding a third consumer is as easy as adding another |
| automaton instantiation, which takes only one line of code |
| (<code>consumer3: Consumer();</code>). Changing the behavior of all consumers only |
| requires changes to the common automaton definition. Automaton |
| definition/instantiation allows for scalability and reuse, and also improves |
| maintainability.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition/instantiation can be eliminated, by replacing all |
| automaton instantiations by the automaton definitions that they instantiate, |
| and changing the automaton definition header (<code>automaton def Consumer():</code>) by |
| an automaton header (<code>automaton consumer1:</code>). If we do that for the example |
| above, we obtain the original specification from the beginning of this lesson. |
| The two specifications are functionally equivalent. Automaton instantiation |
| <code>consumer1</code> is also often referred to as automaton <code>consumer1</code>, when there |
| is no confusion.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-aut-def-params">Parametrized automaton definitions</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| In the <a href="#tut-reuse2-chapter-aut-def-inst">previous lesson</a>, automaton |
| definition/instantiation was used to obtain two identical automata, while only |
| having to specify their behavior once. What we have seen so far, is enough for |
| exactly identical automata, but not for nearly identical automata. Consider the |
| following two nearly identical consumers:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton consumer1: |
| disc list int buffer = []; |
| |
| location: |
| initial; |
| edge provide? when size(buffer) < 2 do buffer := buffer + [?]; |
| end |
| |
| automaton consumer2: |
| disc list int buffer = []; |
| |
| location: |
| initial; |
| edge provide? when size(buffer) < 3 do buffer := buffer + [?]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The consumers can accept products that the producer provides (channel |
| <code>provide</code>). They store the identification numbers of those products in a |
| <code>buffer</code>. The two consumers are identical except for the number of products |
| that they can accept: the first consumer can accept two products, the second |
| producer can accept three products. We can still use automaton definition and |
| instantiation to model the consumer only once, but we need to parametrize the |
| automaton definition:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Consumer(alg int capacity): |
| disc list int buffer = []; |
| |
| location: |
| initial; |
| edge provide? when size(buffer) < capacity do buffer := buffer + [?]; |
| end |
| |
| consumer1: Consumer(2); |
| consumer2: Consumer(3);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>Consumer</code> automaton definition now has a parameter named <code>capacity</code> |
| that indicates how many identification numbers can be stored in its <code>buffer</code>. |
| The automaton instantiations <code>consumer1</code> and <code>consumer2</code> provide an |
| argument (<code>2</code> and <code>3</code> respectively) to match the parameter of <code>Consumer</code>. |
| That is, the instantiations indicate their <code>capacity</code>. Using parameters, the |
| <code>Consumer</code> automaton definition models the behavior of both automata |
| <code>consumer1</code> and <code>consumer2</code>, even though they have different capacities.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The details of the different kind of parameters of automaton definitions are |
| explained in the <a href="#tut-reuse2-chapter-aut-def-param-kinds">next lesson</a>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-aut-def-param-kinds">Automaton definition parameters</h4> |
| <div class="paragraph"> |
| <p> |
| |
| In the <a href="#tut-reuse2-chapter-aut-def-params">previous lesson</a>, an automaton |
| definition with parameter was used. The parameter was an algebraic parameter, |
| which is only one of the different kinds of automaton definition parameters. |
| This lesson explains each of them:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-tut-reuse2-aut-def-param-kinds-alg">Algebraic parameters</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-reuse2-aut-def-param-kinds-event">Event parameters</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-reuse2-aut-def-param-kinds-loc">Location parameters</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-reuse2-aut-def-param-kinds-aut">Automaton parameters</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>This lesson also explains how to use |
| <a href="#lang-tut-reuse2-aut-def-param-kinds-multiple">multiple parameters</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-reuse2-aut-def-param-kinds-alg">Algebraic parameters</h5> |
| <div class="paragraph"> |
| <p>An algebraic parameter is similar to an |
| <a href="#tut-reuse1-chapter-algebraic-variables">algebraic variable</a>. Arbitrary |
| values or expressions of matching type can be provided as arguments in |
| automaton instantiations. For instance, consider the following partial CIF |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int accept, provide; |
| |
| automaton def Buffer(alg int capacity): |
| disc list int buf = []; |
| |
| location: |
| initial; |
| edge accept? when size(buf) < capacity do buf := buf + [?]; |
| edge provide!buf[0] when size(buf) > 0 do buf := buf[1:]; |
| end |
| |
| buffer1: Buffer(5);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>Buffer</code> has an algebraic parameter that indicates the |
| <code>capacity</code> of the buffer. The buffer can <code>accept</code> something when it has not |
| yet reached its capacity. It can <code>provide</code> something when the buffer is not |
| empty. Automaton instantiation <code>buffer1</code> has value <code>5</code> as its parameter. |
| Value <code>5</code> is an integer number, which matches the integer type (<code>int</code>) of |
| the <code>capacity</code> parameter.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Algebraic parameters can be used inside an automaton definition, wherever a |
| value is expected, e.g. in guards, updates, initial values of discrete |
| variables, and invariants. The expression that is provided by the instantiation |
| is essentially filled in wherever the parameter is used. The above is |
| equivalent to:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int accept, provide; |
| |
| automaton buffer1: |
| disc list int buf = []; |
| |
| location: |
| initial; |
| edge accept? when size(buf) < 5 do buf := buf + [?]; |
| edge provide!buf[0] when size(buf) > 0 do buf := buf[1:]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-reuse2-aut-def-param-kinds-event">Event parameters</h5> |
| <div class="paragraph"> |
| <p>Event parameters allow different instantiations to synchronize with different |
| events or to communicate over different |
| <a href="#tut-channels-chapter-intro">channels</a>. For instance, consider the |
| following partial CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int generate, pass_along, exit; |
| |
| automaton def Buffer(event int accept, provide): |
| disc int buffer; |
| |
| location accepting: |
| initial; |
| edge accept? do buffer := ? goto providing; |
| |
| location providing: |
| edge provide!buffer goto accepting; |
| end |
| |
| buffer1: Buffer(generate, pass_along); |
| buffer2: Buffer(pass_along, exit);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>Buffer</code> is parametrized with two channels, one to |
| <code>accept</code> a product into the one place buffer, and one to <code>provide</code> it to |
| some other part of the system. The first buffer (<code>buffer1</code>) accepts products |
| via the <code>generate</code> channel, and provides products via the <code>pass_along</code> |
| channel. The second buffer (<code>buffer2</code>) accepts products via the |
| <code>pass_along</code> channel, and provides products via the <code>exit</code> channel. The |
| first buffer uses the <code>pass_along</code> channel as its <code>provide</code> channel |
| parameter, and the second buffer uses that same <code>pass_along</code> channel as its |
| <code>accept</code> channel parameter. The first buffer thus provides its items to the |
| second buffer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Event and channel parameters can be used inside an automaton definition, |
| wherever an event or channel is expected, e.g. on edges and in |
| <a href="#tut-basics-chapter-alphabet">alphabets</a> if |
| <a href="#lang-tut-basics-alphabet-explicit">explicitly specified</a>. The event or |
| channel that is provided by the instantiation is essentially filled in wherever |
| the parameter is used. The above is equivalent to:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event int generate, pass_along, exit; |
| |
| automaton buffer1: |
| disc int buffer; |
| |
| location accepting: |
| initial; |
| edge generate? do buffer := ? goto providing; |
| |
| location providing: |
| edge pass_along!buffer goto accepting; |
| end |
| |
| automaton buffer2: |
| disc int buffer; |
| |
| location accepting: |
| initial; |
| edge pass_along? do buffer := ? goto providing; |
| |
| location providing: |
| edge exit!buffer goto accepting; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| <div class="sect5"> |
| <h6 id="lang-tut-reuse2-aut-def-param-kinds-event-restrictions">Channel parameter usage restrictions</h6> |
| <div class="paragraph"> |
| <p>If an event parameter is actually a channel (it has a data type), it may also |
| be called a <em>channel parameter</em>. By default, a channel parameter can be used to |
| send, receive, or synchronize. However, it is also possible to restrict the |
| allowed usages. By putting certain event usage restriction flags after the name |
| of the channel parameter, only those usages are allowed. The available flags |
| are <code>!</code> to allow sending, <code>?</code> to allow receiving, and <code>~</code> to allow |
| synchronizing. Duplicate flags are not allowed, the <code>!</code> should be before the |
| <code>?</code> flag, and the <code>!</code> and <code>?</code> flags should be before the <code>~</code> flag.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By restricting the usages, you can immediately see how a channel parameter is |
| used within the automaton definition, as only the usages indicates by the |
| parameter are allowed. It serves as sort of documentation of the intention of |
| the channel parameter. This is much simpler than finding the actual usages of |
| the parameter in the automaton. However, note that the parameter indicates the |
| allowed usages, and doesn’t guarantee that the event/parameter is actually used |
| at all.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another benefit of restricting the usages, is that it makes it possible to spot |
| mistakes. You might for instance use a channel parameter on an edge (e.g. |
| <code>edge e</code>), but forget to include the send part (e.g. <code>edge e!1</code>). If the |
| parameter only allows sending, the accidental synchronization (<code>edge e</code>) is |
| reported as an invalid use. Without the usage checking, you might not encounter |
| the problem until for instance simulation, where it is much more difficult to |
| find the cause.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the example above, we have the following <em>header</em> of the <code>Buffer</code> |
| definition:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Buffer(event int accept, provide):</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We can change this as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Buffer(event int accept?, provide!):</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This makes it clearer that the <code>accept</code> channel is used to receive a |
| product into the buffer, and the <code>provide</code> channel is used send a product |
| from the buffer.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-reuse2-aut-def-param-kinds-loc">Location parameters</h5> |
| <div class="paragraph"> |
| <p>An earlier lesson explained how a |
| <a href="#tut-data-chapter-locs-as-var">location can be used as a variable</a>. Using |
| location parameters, automaton definitions can be supplied with different |
| locations. For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Machine(location other_processing): |
| location heat_up: |
| initial; |
| edge when not other_processing goto processing; |
| |
| location processing: |
| edge tau goto cool_down; |
| |
| location cool_down: |
| edge tau goto heat_up; |
| end |
| |
| machine1: Machine(machine2.processing); |
| machine2: Machine(machine1.processing);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>Machine</code> represents a machine that can heat up, process |
| something, cool down, and repeat that forever. The system consists of two of |
| those machines. The machines can not start processing if the other machine is |
| already processing. That is, the machines perform |
| <a href="http://en.wikipedia.org/wiki/Mutual_exclusion">mutually exclusive</a> |
| processing. If the first machine is in its <code>processing</code> location, the other |
| can’t also be processing (in its own <code>processing</code> location). To prevent a |
| machine from starting to process if the other machine is already processing, |
| each machine needs to know whether the other is already processing. Therefore, |
| automaton definition <code>Machine</code> is parametrized with a location parameter |
| <code>other_processing</code>, that indicates whether the other machine is currently |
| processing (in its <code>processing</code> location). This parameter is used as a guard |
| that determines whether a transition from location <code>heat_up</code> to location |
| <code>processing</code> is allowed. Automaton instantiation <code>machine1</code> provides the |
| first machine with the <code>processing</code> location of the second machine, by |
| using <code>machine2.processing</code> as its instantiation argument.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Location parameters can be used inside an automaton definition, wherever a |
| <a href="#tut-values-chapter-booleans">boolean</a> value is expected, e.g. in guards. |
| The location that is provided by the instantiation is essentially filled in |
| wherever the parameter is used. The above is equivalent to:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton machine1: |
| location heat_up: |
| initial; |
| edge when not machine2.processing goto processing; |
| |
| location processing: |
| edge tau goto cool_down; |
| |
| location cool_down: |
| edge tau goto heat_up; |
| end |
| |
| automaton machine2: |
| location heat_up: |
| initial; |
| edge when not machine1.processing goto processing; |
| |
| location processing: |
| edge tau goto cool_down; |
| |
| location cool_down: |
| edge tau goto heat_up; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-reuse2-aut-def-param-kinds-aut">Automaton parameters</h5> |
| <div class="paragraph"> |
| <p>When multiple declarations (variables, locations, etc) from one automaton are |
| to be supplied as parameters to another automaton, it is also possible to |
| supply the entire automaton as a parameter, but only if the provided automaton |
| is an instantiation of an automaton definition. Consider for instance the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Sensor(): |
| event go_on, go_off; |
| |
| location off: |
| initial; |
| edge go_on goto on; |
| |
| location on: |
| edge go_off goto off; |
| end |
| |
| sensor1: Sensor(); |
| sensor2: Sensor(); |
| |
| automaton def Actuator(Sensor sensor): |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on when sensor.on goto on; |
| |
| location on: |
| edge turn_off when sensor.off goto off; |
| end |
| |
| actuator1: Actuator(sensor1);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>Sensor</code> models a sensor that can go on an off. Both |
| <code>sensor1</code> and <code>sensor2</code> are actual sensors. Automaton definition |
| <code>Actuator</code> models an actuator that can be turned on if a sensor is on, and be |
| turned off if that same sensor is off. The <code>actuator1</code> automaton is provided |
| <code>sensor1</code> as sensor. If <code>sensor1</code> goes on, <code>actuator1</code> is turned on, and |
| if <code>sensor1</code> goes off, <code>actuator1</code> is turned off. <code>sensor2</code> going on or |
| off has no effect on <code>actuator1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton parameters can be used inside an automaton definition, to refer to |
| declarations inside the automaton supplied for the automaton parameter. The |
| automaton that is provided by the instantiation is essentially filled in |
| wherever the parameter is used. The above is equivalent to:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton sensor1: |
| event go_on, go_off; |
| |
| location off: |
| initial; |
| edge go_on goto on: |
| |
| location on: |
| edge go_off goto off: |
| end |
| |
| automaton sensor2: |
| event go_on, go_off; |
| |
| location off: |
| initial; |
| edge go_on goto on: |
| |
| location on: |
| edge go_off goto off: |
| end |
| |
| automaton actuator1: |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on when sensor1.on goto on; |
| |
| location on: |
| edge turn_off when sensor1.off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-reuse2-aut-def-param-kinds-multiple">Multiple parameters</h5> |
| <div class="paragraph"> |
| <p>It is possible to use multiple parameters of the same kind, as well as |
| different kinds of parameters:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def X(event a, b; alg real c; event d): |
| ... |
| end |
| |
| event z; |
| |
| x: X(z, z, 3 * 5, z);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>X</code> has four parameters: <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code>. |
| Since <code>a</code> and <code>b</code> are both event parameters, a comma (<code>,</code>) is used to |
| make sure the <code>event</code> keyword does not need to be repeated for parameter |
| <code>b</code>. Algebraic parameter <code>d</code> is of a different kind, and is therefore |
| separated using a semicolon (<code>;</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton instantiation <code>x</code> instantiates <code>X</code> with the event <code>z</code> (for the |
| first, second, and fourth parameters), and value 15.0 (<code>3 * 5</code>, for the third |
| parameter).</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-groups">Groups</h4> |
| <div class="paragraph"> |
| <p> |
| |
| For large CIF specifications with many automata, it can be beneficial to add |
| more structure to the specification. For this purpose, CIF has <em>groups</em>. Groups |
| are named collections of automata and other declarations. For instance, |
| consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group factory: |
| group hall1: |
| automaton machine1: |
| ... |
| end |
| |
| automaton machine2: |
| ... |
| end |
| end |
| |
| group hall2: |
| automaton machine1: |
| ... |
| end |
| |
| automaton machine2: |
| ... |
| end |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specifications features four automata that model the behavior of machines. |
| The details of the actual automata are omitted, as they are irrelevant for this |
| lesson. All four machines are in the same factory, but they are divided into |
| two halls. This physical subdivision is expressed in the CIF specification |
| using groups named <code>factory</code>, <code>hall1</code>, and <code>hall2</code>. While in this case |
| the subdivision into a hierarchical specification structure is based on the |
| physical subdivision of the actual system, the modeler is free to base the |
| specification structure on other criteria.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider also the following partial CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group configuration: |
| const int MAX_PRODUCTS = 1500; |
| const real MAX_PRODUCTION_TIME = 3.7; |
| const real ARRIVAL_RATE = 28.6; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>configuration</code> group is used to group together several configuration |
| values, modeled by constants. By grouping these constants together, it is more |
| clear that they together are the configuration settings of the system, and that |
| they belong together.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Finally, consider the following CIF specification, based on the |
| <a href="http://en.wikipedia.org/wiki/Nonlinear_system">non-linear system</a> |
| from the lesson on <a href="#tut-time-chapter-equations">equations</a>.</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group tank: |
| cont V = 5; |
| alg real Qi; |
| alg real Qo; |
| |
| equation V' = Qi - Qo; |
| equation Qi = 1; |
| equation Qo = sqrt(V); |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By grouping the declarations and their equations together, it is becomes clear |
| that together they model a <code>tank</code>. This is especially useful if other parts |
| of the specification model something different.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-group-defs">Group definitions</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Similar to how <a href="#tut-reuse2-chapter-aut-def-inst">automaton definitions</a> can |
| be used for reuse of automata, group definitions can be used for reuse of |
| groups:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton def Machine(): |
| location: |
| initial; |
| ... |
| end |
| |
| group def Hall(): |
| machine1: Machine(); |
| machine2: Machine(); |
| end |
| |
| group def Factory(): |
| hall1: Hall(); |
| hall2: Hall(); |
| end |
| |
| factory1: Factory();</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton definition <code>Machine</code> models a machine, but most of the details are |
| omitted here, as they are not relevant for this lesson. Group definition |
| <code>Hall</code> models that each hall has two machines. Similarly, group definition |
| <code>Factory</code> models that each factory has two halls.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Automata and groups are both <em>components</em> in CIF. Automaton definitions and |
| group definitions can together be called <em>component definitions</em>. If we |
| eliminate all component definitions and their instantiations, by replacing |
| instantiations by their definitions, we get the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group factory1: |
| group hall1: |
| automaton machine1: |
| location: |
| initial; |
| ... |
| end |
| |
| automaton machine2: |
| location: |
| initial; |
| ... |
| end |
| end |
| |
| group hall2: |
| automaton machine1: |
| location: |
| initial; |
| ... |
| end |
| |
| automaton machine2: |
| location: |
| initial; |
| ... |
| end |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Group definitions may be <a href="#tut-reuse2-chapter-aut-def-params">parametrized</a> |
| using the same <a href="#tut-reuse2-chapter-aut-def-param-kinds">kinds of parameters</a> |
| as automaton definitions.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-imports">Imports</h4> |
| <div class="paragraph"> |
| <p> |
| For large systems, having to model the entire system in a single CIF file can |
| lead to long CIF specifications. Being able to split that single CIF file into |
| multiple CIF files can help. Consider the following two CIF specifications in |
| CIF files <code>producer.cif</code> and <code>consumer.cif</code> respectively:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// producer.cif |
| |
| event provide; |
| |
| automaton producer: |
| location: |
| initial; |
| edge provide; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// consumer.cif |
| |
| import "producer.cif"; |
| |
| automaton consumer: |
| location: |
| initial; |
| edge provide; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The two CIF specifications together form a simplified producer/consumer system. |
| The <code>producer.cif</code> file declares the <code>provide</code> event and the <code>producer</code> |
| automaton. The <code>producer</code> can <code>provide</code> a product.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>consumer.cif</code> file declares the <code>consumer</code> automaton, that can accept |
| products provided by a producer. The <code>provide</code> event is not declared in that |
| CIF specification. However, the <code>producer.cif</code> file is imported, which does |
| declare that event. By importing another CIF specification, all declarations |
| from that imported CIF specification (<code>producer.cif</code> in the example) become |
| available in the importing CIF specification, i.e. in the specification that |
| does the import (<code>consumer.cif</code> in the example).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The result of the import in <code>consumer.cif</code> is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event provide; |
| |
| automaton producer: |
| location: |
| initial; |
| edge provide; |
| end |
| |
| automaton consumer: |
| location: |
| initial; |
| edge provide; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>You can think of an import as being replaced by the content of the imported |
| file. The <code>producer.cif</code> file contains only its own content, while the |
| <code>consumer.cif</code> file contains the contents of both files, due to the use of |
| the import.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If one CIF specification is merged into another CIF specification, the names of |
| the declarations in both CIF specifications must be different. It is not |
| allowed to have declarations with the same name in multiple CIF specifications. |
| For instance, in the example above, if the <code>provide</code> event were declared in |
| both CIF specifications, the imports would be invalid. Exceptions to this rule |
| are discussed in one of the next lessons, which explains the relation between |
| <a href="#tut-reuse2-chapter-imports-groups">imports and groups</a>.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-imports-libraries">Imports and libraries</h4> |
| <div class="paragraph"> |
| <p> |
| Using <a href="#tut-reuse2-chapter-imports">imports</a>, it is possible to make |
| libraries that can be used by multiple CIF specifications. For instance, |
| consider the following CIF specification in file <code>math.cif</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// math.cif |
| |
| func int inc(int x): |
| return x + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This CIF specification declares a single function <code>inc</code> that takes an integer |
| number and returns that number incremented by one. Now also consider the |
| following CIF specification in file <code>counter.cif</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// counter.cif |
| |
| import "math.cif"; |
| |
| automaton counter: |
| disc int count = 0; |
| |
| location: |
| initial; |
| edge tau do count := inc(count); |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By importing the <code>math.cif</code> file, the <code>counter</code> automaton can use the |
| <code>inc</code> function. Other CIF files could similarly import the <code>math.cif</code> file, |
| essentially turning <code>math.cif</code> into a library.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is possible to make a function library, consisting of commonly used |
| functions, a constant library, with commonly used constants, or an automaton |
| definition library, with automaton definitions. As libraries are just CIF |
| files, they can contain anything as long as they are valid CIF files. |
| Essentially, every CIF file that is imported in more than one other CIF file |
| can be considered a library.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The import as used above, only works if both CIF files are in the same |
| directory. Library files however, are often placed in a different directory. |
| Consider the same two CIF files, but organized into directories (or folders) |
| as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/reuse2/library_dir_tree.png" alt="library dir tree"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Directory <code>system</code> contains a sub-directories named <code>libraries</code>, which |
| contains the <code>math.cif</code> library. The <code>system</code> directory also contains the |
| <code>counter.cif</code> file. The import in the <code>counter.cif</code> file needs to be |
| adapted to refer to the <code>math.cif</code> file in the <code>libraries</code> directory:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// counter.cif |
| |
| import "libraries/math.cif"; |
| |
| automaton counter: |
| disc int count = 0; |
| |
| location: |
| initial; |
| edge tau do count := inc(count); |
| end</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-imports-groups">Imports and groups</h4> |
| <div class="paragraph"> |
| <p> |
| Large systems can be hierarchically modeled using |
| <a href="#tut-reuse2-chapter-groups">groups</a>. When using imports, two specifications |
| may not have declarations with the same name. Groups however, are the exception |
| to this rule. Consider a factory with two machines, each consisting of two |
| parts. We can model this using five files, one for each of the parts of the |
| machines, and one for the factory as a whole. The following CIF specifications |
| show the contents of the five CIF files, where the comment at the first line |
| indicates which file it is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// p1.cif |
| |
| group machine1: |
| automaton part1: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// p2.cif |
| |
| group machine1: |
| automaton part2: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// p3.cif |
| |
| group machine2: |
| automaton part1: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// p4.cif |
| |
| group machine2: |
| automaton part2: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// factory.cif |
| |
| import "p1.cif"; |
| import "p2.cif"; |
| import "p3.cif"; |
| import "p4.cif";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The four CIF specifications for the machine parts differ only in their group |
| and automaton names. Their implementations are kept identical for simplicity. |
| The <code>factory.cif</code> file imports all four part specifications, which together |
| form the full factory. The effect of the imports in <code>factory.cif</code> is the |
| following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group machine1: |
| automaton part1: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| |
| automaton part2: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end |
| |
| group machine2: |
| automaton part1: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| |
| automaton part2: |
| location idle: |
| initial; |
| edge tau goto running; |
| |
| location running: |
| edge tau goto idle; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For groups with the same name, the contents of the groups is merged together. |
| That is, automaton <code>part1</code> in the <code>machine1</code> group from one CIF file, and |
| the automaton <code>part2</code> in that same <code>machine1</code> group from another CIF file, |
| end up in a single <code>machine1</code> group after eliminating the imports.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, contents of groups with the same name are merged into a single |
| group. This works also for groups in groups, groups in groups in groups, etc. |
| If two CIF files that are imported both contain a group <code>a</code> and in both CIF |
| files those groups contain a group <code>b</code>, then the contents of both <code>a</code> |
| groups are merged, and also the contents of both <code>b</code> groups are merged. It is |
| not allowed for different CIF files to have declarations with the same name in |
| the same group. It is allowed to have declarations with the same name in |
| different groups. The file itself (the top level) can be considered a group as |
| well.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-namespaces">Namespaces</h4> |
| <div class="paragraph"> |
| <p> |
| |
| When using <a href="#tut-reuse2-chapter-imports-groups">imports and groups</a> to model |
| large hierarchical systems, it is a common pattern to have groups around the |
| entire specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group factory: |
| group machine1: |
| group part1: |
| automaton sensor1: |
| ... |
| end |
| |
| automaton actuator1: |
| ... |
| end |
| end |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The groups around the entire specification lead to additional |
| <a href="http://en.wikipedia.org/wiki/Indentation_%28typesetting%29">indentation</a>. |
| As this is a common pattern, the CIF language provides <em>namespaces</em> to reduce the |
| impact of large numbers of top level groups:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">namespace factory.machine1.part1; |
| |
| automaton sensor1: |
| ... |
| end |
| |
| automaton actuator1: |
| ... |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>factory.machine1.part1</code> namespace has exactly the same effect as the |
| original three groups. Both specifications can thus be considered identical.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-reuse2-chapter-input-variables">Input variables</h4> |
| <div class="paragraph"> |
| <p> |
| |
| <em>Input variables</em> can be used to model that some data exists, without |
| specifying the value or how or when the value changes. Input variables are used |
| in cases where the CIF model is to be connected something else that provides |
| the values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-hardware-example">Hardware example</h5> |
| <div class="paragraph"> |
| <p>The CIF model may for instance be a controller that is to be connected to a |
| piece of physical hardware. The input variables then model sensors, for which |
| the behavior is not modeled in the CIF model. As an example, consider the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">input bool sensor; |
| |
| automaton controller: |
| cont t der 1; |
| alg bool actuator = on; |
| |
| location off: |
| initial; |
| edge when sensor do t := 0 goto waiting; |
| |
| location waiting: |
| edge when not sensor goto off; |
| edge when t > 1.5 goto on; |
| |
| location on: |
| edge when not sensor goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Input variable <code>sensor</code> models a digital sensor. When the sensor is on, the |
| variable has value <code>true</code> and when the sensor is off, the variable has value |
| <code>false</code>. When the sensor is on and when it is off is not known, and thus not |
| modeled in the CIF specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>controller</code> waits (in location <code>off</code>) for the sensor to go on, and |
| then resets continuous variable <code>t</code> to start measuring <code>1.5</code> time units |
| (in location <code>waiting</code>). If that much time has passed, it goes to location |
| <code>on</code>. If the sensor goes off then, or while it is waiting, it goes back to |
| location <code>off</code>. Thus, the <code>controller</code> is only <code>on</code> if the sensor goes |
| on, <code>1.5</code> time units have passed, and the sensor remains on.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>actuator</code> algebraic variable models that an actuator is only on if the |
| <code>controller</code> is in its on location. The <code>actuator</code> is then on if the sensor |
| is one, and <code>1.5</code> time units have passed. The actuator is always turned off |
| when the sensor is off.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Without a physical hardware system, the CIF specification is incomplete, as the |
| value of the sensor is not known. The input variable acts as a placeholder for |
| the actual sensor. If the CIF specification were to be coupled to a physical |
| hardware system with a sensor and an actuator, the CIF model would then control |
| the actuator based on the sensor values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-co-simulation-example">Co-simulation example</h5> |
| <div class="paragraph"> |
| <p>A CIF specification could model a part of a system, while another part of that |
| same system is modeled in another system or language, such as |
| <a href="http://www.mathworks.nl/products/simulink/">Simulink</a>. Consider for instance |
| a tank filled with water. Water flows out of the tank constantly. By opening a |
| value, water also flows in to the tank. Consider the following CIF |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">input real level; |
| |
| automaton valve: |
| disc bool open = true; |
| |
| location: |
| initial; |
| edge when open and level >= 10 do open := false; |
| edge when not open and level <= 2 do open := true; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The water <code>level</code> is modeled as an input variable, meaning it is obtained |
| from the Simulink model. The CIF specification models the valve, and the |
| controller that opens and closes the value, based on the water level. It keeps |
| the level between <code>2</code> and <code>10</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF model obtains the water level from Simulink by means of input variable |
| <code>level</code>. It also provides the <code>open</code> variable of the <code>valve</code> automaton to |
| Simulink. This variable can be used in Simulink to model how the water level |
| changes over time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Without the Simulink model, the CIF specification is incomplete, as the water |
| level is not known. The input variable acts as a placeholder for the actual |
| water level. If the CIF specification were to be coupled to a Simulink model |
| that models the water level, the CIF specification would control the valve |
| based on the water level.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-cif-models-example">CIF models example</h5> |
| <div class="paragraph"> |
| <p>Input variables can also be used to couple CIF models. Consider again the above |
| water level controller example. It models the valve and controls the valve, but |
| does not model the water level. The following CIF specification could be used |
| to model the water level:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont level der if valve.open: 1 else -1 end; |
| |
| group valve: |
| input bool open; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Continuous variable <code>level</code> models the water level. The water level increases |
| (derivative <code>1</code>) if the valve is open, and decreases (derivative <code>-1</code>) |
| otherwise. The <code>open</code> variable from the <code>valve</code> is used, but this variable |
| is an input variable, and the value is not known in this specification. Input |
| variable <code>open</code> acts as a placeholder for a value, and group <code>valve</code> acts |
| as a placeholder for automaton <code>valve</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The two CIF specifications both model a part of the system. One specification |
| models the water level, and has a placeholder for the variable that indicates |
| whether the valve is open. The other specification models the valve and |
| controls it, but has a placeholder for the water level. If we couple the two |
| CIF specifications, they provide each other with actual variables for each |
| others input variables.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The two specifications can be coupled or <em>merged</em> together:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont level = 0.0 der if valve.open: 1 else -1 end; |
| |
| automaton valve: |
| disc bool open = true; |
| |
| location: |
| initial; |
| edge when open and level >= 10 do open := false; |
| edge when not open and level <= 2 do open := true; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Using input variables to couple CIF specifications is somewhat similar to using |
| <a href="#tut-reuse2-chapter-imports">imports</a> to split a CIF specification over |
| multiple files. There are however important differences.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first difference is that when using imports, one CIF specification is |
| coupled to another CIF specification. The coupling is hard-coded in the CIF |
| specification, and can not be changed without changing the import. When using |
| input variables and merging, it is possible to couple a CIF specification |
| to a second CIF specification, and later couple it with a third, different |
| specification instead. The decision about which models to merge can thus be |
| postponed, and does not require changes to any of the CIF specifications.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another difference is that with imports it is not allowed to have declarations |
| with the same name in different CIF specifications (except for groups), while |
| with the merger this is allowed in many situations. See the documentation of |
| the <a href="#tools-chapter-mergecif">CIF merger</a> tool for further details on what can |
| be merged using that tool.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-stochastics">Stochastics</h3> |
| <div class="sect3"> |
| <h4 id="tut-stochastics-chapter-intro">Stochastics</h4> |
| <div class="paragraph"> |
| <p> |
| For many things in the world, the behavior is not the same every time. An |
| example is a |
| <a href="http://en.wikipedia.org/wiki/Coin_toss">coin toss</a>, |
| where |
| the result can be either heads or tails. Tossing a coin exhibits |
| <a href="http://en.wikipedia.org/wiki/Randomness">randomness</a>. |
| It is possible to |
| model the different variants in a CIF model without specifying the likelihood |
| of each of the outcomes. This approach was used in the lesson on |
| <a href="#tut-basics-chapter-non-determinism">non-determinism</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| It is however also possible to explicitly specify the likelihood of each of the |
| outcomes in the CIF model, using a <em>stochastic distribution</em> (also called |
| <a href="http://en.wikipedia.org/wiki/Probability_distribution">probability distribution</a>). |
| A stochastic |
| distribution describes how likely the different outcomes are. There are many |
| different stochastic distributions. The |
| <a href="http://en.wikipedia.org/wiki/Bernoulli_distribution">Bernoulli distribution</a> |
| for instance, can be |
| used to model things with two potential outcomes, such as a coin toss.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton coin_toss: |
| disc dist bool d = bernoulli(0.5); |
| disc bool outcome; |
| |
| location toss: |
| initial; |
| edge do (outcome, d) := sample d goto result; |
| |
| location result: |
| edge when outcome goto heads; |
| edge when not outcome goto tails; |
| |
| location heads: |
| edge tau goto toss; |
| |
| location tails: |
| edge tau goto toss; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>d</code> holds a stochastic distribution that produces |
| <a href="#tut-values-chapter-booleans">boolean values</a> (<code>true</code> or <code>false</code>), as |
| indicated by its <code>dist bool</code> |
| <a href="#tut-values-chapter-types-values-exprs">type</a>. In this case it holds a |
| Bernoulli distribution, with a probability of <code>0.5</code> (or chance of 50%) for |
| <code>true</code>, and thus also the same probability/chance for <code>false</code> (the only |
| other possible outcome).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>bernoulli</code> function is used to create a Bernoulli distribution with the |
| proper parameter (probability of <code>0.5</code> for <code>true</code>). Different distributions |
| have different parameters. See the language reference documentation for further |
| details. Distribution functions, such as the <code>bernoulli</code> function can be used |
| to create distributions with specific parameters, and may only be used to |
| initialize discrete variables.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Initially, the automaton is in its <code>toss</code> location, where the coin can be |
| tossed. The edge uses the <code>sample</code> operator to get a <em>sample</em> from the |
| bernoulli distribution. Each time the distribution is sampled, the <code>outcome</code> |
| is either a <code>true</code> value or a <code>false</code> value. As we used a probability of |
| <code>0.5</code> for both outcomes, half of the times <code>true</code> will be the outcome, |
| and the other half of the times <code>false</code> will be the outcome, if we were to |
| sample infinitely many times.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Sampling does not only result in the <code>outcome</code>, but also the distribution |
| itself. This is further explained in one of the next lessons, which explains |
| <a href="#tut-stochastics-chapter-pseudo-randomness">pseudo-randomness</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The result of sampling is stored in the <code>outcome</code> variable. In the <code>result</code> |
| location, the sampling result is used to make a decision to go to either the |
| <code>heads</code> location (<code>true</code> outcome) or the <code>tails</code> location (<code>false</code> |
| outcome). From there, it is possible to go back to the <code>toss</code> location, to |
| proceed with the next coin toss.</p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-stochastics-chapter-discrete-continuous-constant">Discrete, continuous, and constant distributions</h4> |
| <div class="paragraph"> |
| <p>CIF features over a dozen different stochastic distributions. These |
| distributions can be categorized into three categories: discrete, continuous, |
| and constant distributions. Discrete distributions can result in only a limited |
| number of possible values. Examples include tossing a coin (heads and tails) |
| and throwing a dice (six possible outcomes). Continuous distributions can |
| result in all values from a certain range. Examples include the time it takes |
| for a machine to produce a single product (positive amount of time), and the |
| purity of produced medicine (0% to 100%). Constant distributions are discrete |
| distributions that always result in the same sampled value. They are useful |
| during the development of a model, or for debugging. The remainder of this |
| lesson further explains these three categories, and illustrates them using some |
| examples.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-discrete-distributions">Discrete distributions</h5> |
| <div class="paragraph"> |
| <p>Discrete distributions can result in only a limited number of possible values. |
| The lesson that <a href="#tut-stochastics-chapter-intro">introduced stochastics</a> |
| used the discrete |
| <a href="http://en.wikipedia.org/wiki/Bernoulli_distribution">Bernoulli distribution</a> |
| to model |
| <a href="http://en.wikipedia.org/wiki/Coin_toss">tossing of a coin</a>, which can result |
| in either heads or tails.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Throwing a |
| <a href="http://en.wikipedia.org/wiki/Dice">dice</a> |
| can result in six |
| possible outcomes: 1, 2, 3, 4, 5, and 6. For a fair dice, each of the outcomes |
| is equally likely, with chance 1/6. This can be modeled using a |
| <a href="http://en.wikipedia.org/wiki/Uniform_distribution_(discrete)">discrete uniform distribution</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton dice: |
| disc dist int d = uniform(1, 7); |
| disc int result; |
| disc list int results = []; |
| |
| location throw: |
| initial; |
| edge do (result, d) := sample d goto add; |
| |
| location add: |
| edge do results := results + [result] goto throw; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>uniform</code> function is used to create a uniform integer distribution that |
| produces <a href="#tut-values-chapter-integers">integer</a> samples from the range |
| [1..7) (inclusive on the left side, exclusive on the right side). Each sample |
| is stored in <code>result</code> and added to the <code>results</code>. If we were to simulate |
| this model forever, the <code>results</code> list would contain equal amounts of each of |
| the six values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-continuous-distributions">Continuous distributions</h5> |
| <div class="paragraph"> |
| <p>Continuous distributions return a value from a continuous range. An example is |
| the weight of |
| <a href="http://en.wikipedia.org/wiki/Penny_(United_States_coin)">pennies</a>. |
| This |
| could for instance be approximated using a continuous |
| <a href="http://en.wikipedia.org/wiki/Normal_distribution">normal distribution</a> |
| with a |
| <a href="http://en.wikipedia.org/wiki/Mean">mean</a> |
| of 2.46 grams and a |
| <a href="http://en.wikipedia.org/wiki/Variance">variance</a> |
| of 0.0004 grams:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton pennies: |
| disc dist int d = normal(2.46, 0.0004); |
| |
| location: |
| initial; |
| edge do (weight, d) := sample d; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>normal</code> function is used to create a normal distribution with a mean of |
| <code>2.46</code> and a variance of <code>0.0004</code>. The sampled weight is stored in the |
| <code>weight</code> variable each time the distribution is sampled. The probability of |
| the different weights as a result of the used normal distribution is depicted |
| in the following figure:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tutorial/stochastics/pennies.png" alt="pennies"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-constant-distributions">Constant distributions</h5> |
| <div class="paragraph"> |
| <p>When developing a model with stochastic behavior, it can be hard to validate |
| whether the model behaves correctly, since the stochastic results make it |
| difficult to predict the outcome of experiments. As a result, errors in the |
| model may not be noticed, as they hide in the noise of the stochastic results. |
| One solution is to first make a model without stochastic behavior, validate |
| that model, and then extend the model with stochastic sampling. Extending the |
| model with stochastic behavior is however an invasive change that may introduce |
| new errors. These errors can again be hard to find due to the difficulties to |
| predict the outcome of an experiment. The constant distributions aim to narrow |
| the gap by reducing the amount of changes that need to be done after |
| validation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>With constant distributions, a stochastic model with sampling of distributions |
| is developed, but the stochastic behavior is eliminated by temporarily using |
| constant distributions. The model performs stochastic sampling of values, but |
| with predictable outcome, and thus with predictable experimental results, |
| making validation easier. After validating the model, the constant |
| distributions are replaced with the distributions that fit the mean value and |
| variation pattern of the modeled system, giving a model with stochastic |
| behavior. Changing the used distributions is however much less invasive, making |
| it less likely to introduce new errors at this stage in the development of the |
| model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Constant distributions always produce the same sampled value. Consider the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton dice: |
| disc dist int d = constant(3); // Constant distribution. |
| disc int result; |
| disc list int results = []; |
| |
| location throw: |
| initial; |
| edge do (result, d) := sample d goto add; |
| |
| location add: |
| edge do results := results + [result] goto throw; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This model is identical to the dice model one used earlier in this lesson, |
| except for distribution variable <code>d</code>, which now holds a constant distribution |
| that only produces value <code>3</code> when sampled.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tut-stochastics-chapter-pseudo-randomness">Pseudo-randomness</h4> |
| <div class="paragraph"> |
| <p>So far, the lessons on stochastics used the mathematical notion of stochastic |
| distribution to describe how to model stochastic behavior. Simulating a model |
| with stochastic behavior using a computer is however not stochastic at all. |
| Computer systems are deterministic machines, and have no notion of varying |
| results.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-pseudorandom-number-generator-and-seed">Pseudorandom number generator and seed</h5> |
| <div class="paragraph"> |
| <p>A |
| <a href="http://en.wikipedia.org/wiki/Pseudorandom_number_generator">pseudorandom number generator</a> |
| is used to |
| create stochastic results instead. It starts with an initial |
| <a href="http://en.wikipedia.org/wiki/Random_seed">seed</a>, |
| an integer number. From |
| this seed, a function creates a stream of 'random' values. When looking at the |
| values there does not seem to be any pattern. It is not truly random however. |
| Using the same seed again gives exactly the same stream of numbers. This is the |
| reason to call the function a pseudorandom number generator, as a true random |
| number generator would never produce the exact same stream of numbers.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-simulation-and-initial-seed">Simulation and initial seed</h5> |
| <div class="paragraph"> |
| <p>A sample of a distribution uses one or more numbers from the stream to compute |
| its value. The value of the <em>initial seed</em> thus decides the value of all |
| samples drawn in the simulation. By default, a different seed is used each time |
| you run a simulation, leading to different results each time. You can also |
| explicitly state what seed you want to use when simulating a model. See the |
| <a href="#tools-cifsim-chapter-distr-seeds">Stochastic distributions and seeds</a> page of the simulator for information on how |
| to supply a custom seed for simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>While doing a stochastic simulation study, performing several experiments with |
| the same initial seed invalidates the results, as it is equivalent to copying |
| the outcome of a single experiment a number of times. On the other hand, when |
| looking for the cause of a bug in the model, performing the exact same |
| experiment is useful as outcomes of previous experiments should match exactly.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tut-sampling-and-tuple-results">Sampling and tuple results</h5> |
| <div class="paragraph"> |
| <p>The seed determines the next sampled value. Whenever a distribution is sampled, |
| the seed changes to the one that follows in the stream of random numbers |
| generated by the pseudorandom number generator. This ensures that the next time |
| the distribution is sampled, it results in a different sampled value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In CIF, the seed is stored with the distribution and its parameters. Therefore, |
| sampling does not only result in the sampled value, it also results in an |
| updated distribution, with the same parameters, but a different seed value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton coin_toss: |
| disc dist bool d = bernoulli(0.5); |
| disc bool outcome; |
| |
| location: |
| initial; |
| edge do (outcome, d) := sample d goto result; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>bernoulli</code> function to create a |
| <a href="http://en.wikipedia.org/wiki/Bernoulli_distribution">Bernoulli distribution</a> |
| with parameter <code>0.5</code> |
| (the chance for <code>true</code>). This Bernoulli distribution, along with its |
| parameter and the seed, are stored in variable <code>d</code>. When the distribution |
| in variable <code>d</code> is sampled (<code>sample d</code>), the result is both a sampled |
| value, and a distribution (as a <a href="#tut-values-chapter-tuples">tuple</a>). The |
| distribution is the same distribution with the same parameters, but with an |
| updated seed. The sampled value is usually stored in a variable (<code>outcome</code> |
| in this case). The changed distribution is usually assigned to the same |
| variable that contains the distribution that is sampled, to ensure that we can |
| use the same variable for the next sampling. In other words, variable <code>d</code> |
| is updated with the changed distribution each time it is sampled. The result |
| of sampling is assigned to two variables, using |
| <a href="#lang-tut-values-tuples-unpacking">tuple unpacking</a>.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tut-language-extensions">Language extensions</h3> |
| <div class="sect3"> |
| <h4 id="tut-extensions-chapter-synthesis">Supervisory controller synthesis</h4> |
| <div class="paragraph"> |
| <p> |
| Supervisory controller synthesis (or supervisor synthesis, or just synthesis) |
| is a generative technique, where one derives a supervisory controller from a |
| collection of plants and requirements. Synthesis allows to focus on the <em>what</em>, |
| i.e. which requirements should hold, rather than on the <em>how</em>, i.e. how to |
| implement this in a controller.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div id="lang-tut-extensions-synthesis-plant-req-sup" class="paragraph"> |
| <p>The <em>plants</em> describe capabilities or behavior of a physical system 'as is', |
| without any integrated control. They represent the available behavior of the |
| uncontrolled system. <em>Requirements</em> model (a part of) the functions a system is |
| supposed to perform. They represents behavior that is allowed in the controlled |
| system, or more precisely, they specify the behavior that is not allowed in the |
| controlled system. In other words, requirements restrict the behavior of the |
| plants, to ensure that only the desired behavior remains. The goal of |
| supervisory controller synthesis is to compute a supervisory controller (or |
| <em>supervisor</em>) that enforces the requirements, assuming the behavior of the |
| plants, additionally preventing deadlock and livelock, and without restricting |
| the system any further than is required.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is beyond the scope of the CIF language tutorial to go into the details of |
| supervisory controller synthesis. However, CIF has several features that are |
| used solely of modeling systems for the purpose of supervisory controller |
| synthesis:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-tut-extensions-synthesis-autkind">Automaton kinds</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-extensions-synthesis-invkind">Invariant kinds</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-extensions-synthesis-evtctrl">Event controllability</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-tut-extensions-synthesis-marked">Marker predicates</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>These concepts are explained below. When a model is not used for supervisory |
| controller synthesis, e.g. for simulation, these concepts are usually ignored.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| </p> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-extensions-synthesis-autkind">Automaton kinds</h5> |
| <div class="paragraph"> |
| <p>For supervisory controller synthesis, different kinds of automata are treated |
| in different ways. Regular automata, as used in the language tutorial so far, |
| are specified using only the <code>automaton</code> keyword. Regular automata do not |
| specify a kind for supervisory controller synthesis, and are therefore |
| sometimes also referred to as kindless automata. Synthesis tools typically |
| require knowledge about the purpose of each of the automata, and therefore |
| don’t support regular automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For supervisory controller synthesis, three different kinds of automata are |
| available: plant automata, requirement automata, and supervisor automata. These |
| automata are identical to regular automata, except for the keywords used to |
| declare their intent. The <code>automaton</code> keyword is preceded or replaced by the |
| <code>plant</code>, <code>requirement</code>, or <code>supervisor</code> keyword respectively.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following are two alternative ways to model the same plant |
| automaton:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Plant automaton, long form. |
| plant automaton lamp: |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end |
| |
| // Plant automaton, short form. |
| plant lamp: |
| event turn_on, turn_off; |
| |
| location off: |
| initial; |
| edge turn_on goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-extensions-synthesis-invkind">Invariant kinds</h5> |
| <div class="paragraph"> |
| <p>Similar to automata, different kinds of invariants are treated in different |
| ways for supervisory controller synthesis. Invariants can be declared as plant, |
| requirement, or supervisor invariants, by preceding or replacing the |
| <code>invariant</code> keyword with a <code>plant</code>, <code>requirement</code>, or <code>supervisor</code> |
| keyword respectively.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">invariant lamp.on or lamp.off; // Regular/kindless invariant. |
| |
| plant lamp: |
| event turn_on, turn_off; |
| |
| requirement invariant not off; // Explicit requirement invariant. Long form. |
| requirement not off; // Explicit requirement invariant. Short form. |
| |
| location off: |
| initial; |
| edge turn_on goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first invariant, above the <code>lamp</code> automaton, does not specify an |
| additional supervisory kind keyword, are is therefore a regular invariant, also |
| called a kindless invariant. The second invariant, in the <code>lamp</code> automaton, |
| explicitly specifies a <code>requirement</code> kind and is therefore a requirement |
| invariant. The third and last invariant is identical to the second invariant, |
| except that the <code>invariant</code> keyword has been omitted. It is also a |
| requirement invariant, but written in a shorter form.</p> |
| </div> |
| <div id="lang-tut-extensions-synthesis-invkind-implicit" class="paragraph"> |
| <p>Invariants without an additional keyword to specify their supervisory kind, are |
| regular invariants or kindless invariants. However, if such an invariant is |
| placed in an automaton that has a supervisory kind, the invariant inherits the |
| supervisory kind of that automaton. This is a deprecated feature that will |
| result in a warning. To get rid of the warning, explicitly specify the |
| supervisory kind of the invariant.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant lamp: |
| event turn_on, turn_off; |
| |
| invariant on or off; // Inherits 'plant' kind from automaton. |
| plant invariant on or off; // Explicit plant invariant. Long form. |
| plant on or off; // Explicit plant invariant. Short form. |
| |
| location off: |
| initial; |
| edge turn_on goto on; |
| |
| location on: |
| edge turn_off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first invariant has no explicit supervisory kind specified, and therefore |
| inherits the <code>plant</code> supervisory kind from the automaton. It is thus an |
| invariant that is implicitly a plant invariant. This results in a warning. The |
| second invariant is identical, except for the explicit specification of the |
| <code>plant</code> kind. It is also a plant invariant, but due to the explicit kind |
| specification, there is no warning. The third and last invariant is identical |
| to the second invariant, except that the <code>invariant</code> keyword has been |
| omitted. It is also explicitly a plant invariant, but written in a shorter |
| form. Due to the explicit use of the <code>plant</code> keyword, this variant also gets |
| no warning.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are two forms of invariants: |
| <a href="#tut-data-chapter-stat-invariants">state invariants</a> and |
| <a href="#tut-data-chapter-stat-evt-excl-invariants">state/event exclusion invariants</a>. Both forms can be used for |
| synthesis. For instance, consider the following example of a counter:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant counter: |
| controllable increment, decrement; |
| disc int x = 0; |
| |
| plant invariant 0 <= x and x <= 10; |
| |
| requirement increment needs x < 8; |
| |
| location: |
| initial; |
| edge increment do x := x + 1; |
| edge decrement do x := x - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The counter can be incremented and decremented. The plant invariant specifies |
| that it is not possible for the counter to count negative values, or values |
| more than 10. It is a requirement that synthesis ensures that the counter can |
| only be incremented as long as the counted value is less than 8.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-extensions-synthesis-evtctrl">Event controllability</h5> |
| <div class="paragraph"> |
| <p>Supervisory controller synthesis distinguishes two kinds of |
| <a href="#lang-tut-basics-automata-events">events</a>: controllable events and |
| uncontrollable events.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Uncontrollable events are events that a supervisor can not prohibit, and are |
| usually related to sensors. A typical example are events that indicate that a |
| button has been pushed or released. A button is essentially a sensor that is |
| on if the user pushes the button, and off if the user doesn’t push it. The |
| supervisor can not prevent a user from physically pushing or releasing a |
| button, and can also not determine when the user pushes or releases it. The |
| supervisor thus also can not prevent the events from occurring.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another example is an event that indicates that a moving part has reached its |
| outer position (limit sensor turns on). If the part reaches its outer position, |
| the event will occur. The supervisor can not control the sensor, as it is |
| physically linked to the position of the moving part.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Controllable events may be restricted by a supervisor, and are usually related |
| to actuators. Typical examples are events used to turn a motor on or off, to |
| turn a lamp on or off, or to change the direction of movement.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Even though a supervisor may not be able to control a limit sensor directly, |
| and thus restrict the corresponding events, it may be able to influence it |
| indirectly. For instance, a motor may be available that makes it possible for |
| the part to move. That motor may then be controlled using controllable on and |
| off events. Stopping the motor then makes the part stop moving, ensuring that |
| the part never reaches its outer position, indirectly preventing the limit |
| sensor from turning on, and the corresponding event from happening.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Events and <a href="#tut-channels-chapter-intro">channels</a> in CIF are declared |
| using the <code>event</code> keyword. For controllable events, the <code>event</code> keyword |
| may be preceded or replaced by the <code>controllable</code> keyword. Similarly, |
| for uncontrollable events, the <code>event</code> keyword may be preceded or replaced |
| by the <code>uncontrollable</code> keyword. Similar to event declarations, for |
| <a href="#lang-tut-reuse2-aut-def-param-kinds-event">event parameters</a> the |
| <code>event</code> keyword may by preceded or replaced by the <code>controllable</code> or |
| <code>uncontrollable</code> keyword, for controllable and uncontrollable event |
| parameters respectively.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As a convention, controllable events are given names that start with <code>c_</code>, |
| and uncontrollable events are given names that start with <code>u_</code>. This allows |
| them to be highlighted in different colors.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">controllable c_on, c_off; |
| uncontrollable u_pushed, u_released;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="lang-tut-extensions-synthesis-marked">Marker predicates</h5> |
| <div class="paragraph"> |
| <p>Marking is very weak form of liveness, and is used by supervisory controller |
| synthesis to prevent livelocks, to ensure progress. It is also used to prevent |
| deadlocks. A supervisor per definition ensures that a marked state can always |
| be reached, for the entire system. A system is marked if all its automata are |
| marked. An automaton is marked if its active location is a marked location. In |
| literature, marked location are also called <em>safe</em> locations. Note that |
| deadlock in marked states is not prevented, as a marker state (the state |
| itself) can be reached by not taking any transition. In literature, marked |
| deadlock states are also called <em>final</em> states.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Marking can be specified using <em>marker predicates</em>. Locations can be marked |
| using the <code>marked</code> keyword, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant lamp: |
| controllable c_turn_on, c_turn_off; |
| |
| location off: |
| initial; |
| marked; |
| edge c_turn_on goto on; |
| |
| location on: |
| edge c_turn_off goto off; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this example location <code>off</code> is both initial and marked, while location |
| <code>on</code> is neither initial nor marked.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Marker predicates are very similar to |
| <a href="#tut-data-chapter-init-preds">initialization predicates</a>, as by default, |
| locations are not marked, similar to how by default locations are not initial. |
| Marker predicates can be specified in locations, automata, |
| <a href="#tut-reuse2-chapter-groups">groups</a>, and the top level of the specification |
| (which can be seen as a group), similar to initialization predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following specification shows an example of a variable that is only marked |
| for a certain value:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant counter: |
| controllable c_increment, c_decrement; |
| disc int[0..10] count = 0; |
| |
| marked count = 0; |
| |
| location off: |
| initial; |
| marked; |
| edge c_increment do count := count + 1; |
| edge c_decrement do count := count - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>count</code> of plant automaton <code>counter</code> is only marked if it has |
| value zero. That is, the entire system can only be marked if <code>count</code> is zero. |
| Supervisor synthesis will ensure that it is always possible to get back to a |
| state where <code>count</code> is zero.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="lang-ref-chapter-index">Language reference</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The documentation in this language reference manual serves as reference. |
| It is not intended to be read from beginning to end, but more to look up |
| specific information when needed. The reference documentation generally |
| provides detailed and complete information, but this information may not |
| always be presented in the most accessible way.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The information is divided into categories. The following categories and |
| information is part of the language reference documentation:</p> |
| </div> |
| <div class="paragraph"> |
| <p><em>Syntax</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#lang-ref-syntax-lexical">Lexical syntax</a></p> |
| </li> |
| <li> |
| <p><a href="#lang-ref-syntax-grammar">Grammar</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect2"> |
| <h3 id="lang-ref-syntax-lexical">Lexical syntax</h3> |
| <div class="paragraph"> |
| <p>This page describes the CIF lexical syntax.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect3"> |
| <h4 id="lang-ref-keywords">Keywords</h4> |
| <div class="paragraph"> |
| <p><em>Language keywords</em></p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg disc group post switch |
| alphabet dist id pre tau |
| any do if print text |
| attr edge import printfile time |
| automaton elif initial real to |
| bool else input requirement true |
| break end int return tuple |
| case enum invariant self type |
| const equation list set uncontrollable |
| cont event location string urgent |
| continue false marked supervisor value |
| controllable file monitor svgcopy void |
| def final namespace svgfile when |
| der for needs svgin while |
| dict func now svgmove |
| disables goto plant svgout</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p><em>Trigonometric functions</em></p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">acosh asin cosh sin |
| acos atanh cos tanh |
| asinh atan sinh tan</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p><em>General functions</em></p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">abs empty ln pop sign |
| cbrt exp log pow size |
| ceil floor max round sqrt |
| del fmt min scale</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p><em>Distributions</em></p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">bernoulli erlang lognormal triangle |
| beta exponential normal uniform |
| binomial gamma poisson weibull |
| constant geometric random</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p><em>Expression operators</em></p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">and mod sample |
| div not sub |
| in or</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="lang-ref-terminals">Terminals</h4> |
| <div class="paragraph"> |
| <p>Besides the keyword terminals listed above, CIF features several other |
| terminals:</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>IDENTIFIERTK</code></dt> |
| <dd> |
| <p>An identifier. Defined by the regular expression: |
| <code>[$]?[a-zA-Z_][a-zA-Z0-9_]*</code>. They thus consist of letters, numbers |
| and underscore characters (<code>_</code>). Identifiers may not start with a |
| numeric digit. Keywords take priority over identifiers. To use a |
| keyword as an identifier, prefix it with a <code>$</code> character. |
| The <code>$</code> is not part of the identifier name.</p> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">apple // identifier |
| bear // identifier |
| int // keyword |
| $int // identifier 'int' (override keyword priority with $)</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>RELATIVENAMETK</code></dt> |
| <dd> |
| <p>A relative name. Defined by the regular expression: |
| <code>[$]?[a-zA-Z_][a-zA-Z0-9_]*(\.[$]?[a-zA-Z_][a-zA-Z0-9_]*)+</code>. |
| It thus consists of two or more <code>IDENTIFIERTK</code> joined together |
| with periods (<code>.</code>).</p> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">some_automaton.some_location</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>ABSOLUTENAMETK</code></dt> |
| <dd> |
| <p>An absolute name. Absolute names can be used to refer to objects that are |
| otherwise hidden. It represents an absolute name from the root of the |
| current scope.</p> |
| <div class="paragraph"> |
| <p>Defined by the regular expression: |
| <code>\.[$]?[a-zA-Z_][a-zA-Z0-9_]*(\.[$]?[a-zA-Z_][a-zA-Z0-9_]*)*</code>. |
| It starts with a period (<code>.</code>), and then follows an <code>IDENTIFIER</code> or |
| <code>RELATIVENAMETK</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">.some_event |
| .some_group.some_event</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>ROOTNAMETK</code></dt> |
| <dd> |
| <p>A root name. Absolute names can be used to refer to objects that are |
| otherwise hidden. It represents an absolute name from the root the current |
| specification.</p> |
| <div class="paragraph"> |
| <p>Defined by the regular expression: |
| <code>\^[$]?[a-zA-Z_][a-zA-Z0-9_]*(\.[$]?[a-zA-Z_][a-zA-Z0-9_]*)*</code>. |
| It starts with a circumflex accent (<code>^</code>), and then follows an <code>IDENTIFIER</code> or |
| <code>RELATIVENAMETK</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">^some_group.some_event</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>NUMBERTK</code></dt> |
| <dd> |
| <p>An integer literal. Defined by the regular expression: <code>0|[1-9][0-9]*</code>. |
| Integers thus consist of numeric digits. Only for the number <code>0</code> may an |
| integer literal start with <code>0</code>. E.g. <code>02</code> is invalid.</p> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">0 |
| 1 |
| 123</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>REALTK</code></dt> |
| <dd> |
| <p>A real literal. Defined by the regular expression: |
| <code>(0|[1-9][0-9]*)(\.[0-9]+|(\.[0-9]+)?[eE][\-\+]?[0-9]+)</code>. |
| Simple double literals consist of an integer literal followed by |
| a period (<code>.</code>) and some numeric digits. Double literals using scientific |
| notation start with either an integer literal or a simple double literal. |
| They then contain either an <code>e</code> or <code>E</code>, followed by the exponent. |
| The exponent consists of numeric digits, optionally preceded by <code>+</code> or <code>-</code>.</p> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">0.0 |
| 1e5 |
| 1E+03 |
| 1.05e-78</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1"><code>STRINGTK</code></dt> |
| <dd> |
| <p>A string literal. Defined by the regular expression: |
| <code>\"([^\\\"\n]|\\[nt\\\"])*\"</code>. String literals are enclosed in double |
| quotes (<code>"</code>). String literals must be on a single line and must thus not |
| include new line characters (<code>\n</code>, Unicode U+0A). To include a double quote |
| (<code>"</code>) in a string literal, it must be escaped as <code>\"</code>. Since a |
| backslash (<code>\</code>) serves as escape character, to include a backslash in a string |
| literal it must be escaped as <code>\\</code>. To include a tab character in a string |
| literal, use <code>\t</code>. To include a newline in a string literal, use <code>\n</code>.</p> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">"hello world" |
| "first line\nsecond line"</code></pre> |
| </div> |
| </div> |
| </dd> |
| </dl> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="lang-ref-whitespace">Whitespace</h4> |
| <div class="paragraph"> |
| <p>CIF supports spaces, tabs, and new line characters as whitespace. |
| Whitespace is ignored (except in string literals), but can be used to separate |
| tokens as well as for layout purposes. The use of tab characters is allowed, |
| but should be avoided if possible, as layout will be different for text |
| editors with different tab settings. You may generally format a CIF |
| script as you see fit, and start on a new line when desired.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Normal layout. |
| int x = 5; |
| |
| // Alternative layout. |
| int |
| x = |
| 5 |
| ;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="lang-ref-comments">Comments</h4> |
| <div class="paragraph"> |
| <p>CIF features two types of comments. Single line comments start with |
| <code>//</code> and end at end of the line. Multi line comments start with <code>/*</code> and |
| end at <code>*/</code>. Comments are ignored.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">int x = 5; // Single line comment. |
| |
| int /* some comment */ x = /* some |
| more comments |
| and some more |
| end of the multi line comment */ 5;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="lang-ref-syntax-grammar">Grammar</h3> |
| <div class="paragraph"> |
| <p>Below, the <a href="http://en.wikipedia.org/wiki/Formal_grammar">grammar</a> of the |
| CIF language is shown, in a form closely resembling |
| <a href="http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form">Backus-Naur Form</a> |
| (BNF). The <code>Specification</code> |
| <a href="http://en.wikipedia.org/wiki/Nonterminal_symbol">non-terminal</a> is the |
| <a href="http://en.wikipedia.org/wiki/Start_symbol_(formal_languages)">start symbol</a> |
| of the grammar. Text between quotes are terminals. Names using only upper case |
| letters are defined in the <a href="#lang-ref-syntax-lexical">lexical syntax</a>. The |
| remaining names are the non-terminals of the grammar.</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="bnf">Specification : GroupBody |
| ; |
| |
| GroupBody : OptGroupDecls |
| ; |
| |
| AutomatonBody : OptAutDecls Locations OptIoDecls |
| ; |
| |
| OptGroupDecls : /* empty */ |
| | OptGroupDecls GroupDecl |
| ; |
| |
| GroupDecl : Decl |
| | "import" Imports ";" |
| | "namespace" IDENTIFIERTK ";" |
| | "namespace" RELATIVENAMETK ";" |
| | "func" Types Identifier FuncParams ":" FuncBody |
| | Identifier ":" Name ActualParms ";" |
| | "group" "def" Identifier FormalParms ":" GroupBody "end" |
| | OptSupKind "automaton" "def" Identifier FormalParms ":" AutomatonBody "end" |
| | SupKind "def" Identifier FormalParms ":" AutomatonBody "end" |
| | "group" Identifier ":" GroupBody "end" |
| | OptSupKind "automaton" Identifier ":" AutomatonBody "end" |
| | SupKind Identifier ":" AutomatonBody "end" |
| ; |
| |
| OptAutDecls : /* empty */ |
| | OptAutDecls AutDecl |
| ; |
| |
| AutDecl : Decl |
| | "alphabet" Events ";" |
| | "alphabet" ";" |
| | "monitor" Events ";" |
| | "monitor" ";" |
| | "disc" Type DiscDecls ";" |
| ; |
| |
| Decl : "type" TypeDefs ";" |
| | "enum" Identifier "=" "{" Identifiers "}" ";" |
| | "enum" Identifier "=" Identifiers ";" |
| | OptControllability "event" Identifiers ";" |
| | OptControllability "event" EventType Identifiers ";" |
| | Controllability Identifiers ";" |
| | Controllability EventType Identifiers ";" |
| | "const" Type ConstantDefs ";" |
| | "alg" Type AlgVarsDefs ";" |
| | "input" Type Identifiers ";" |
| | "cont" ContDecls ";" |
| | "equation" Equations ";" |
| | "initial" Expressions ";" |
| | InvariantDecls |
| | "marked" Expressions ";" |
| | IoDecl |
| ; |
| |
| Identifier : IDENTIFIERTK |
| ; |
| |
| Imports : StringToken |
| | Imports "," StringToken |
| ; |
| |
| StringToken : STRINGTK |
| ; |
| |
| TypeDefs : Identifier "=" Type |
| | TypeDefs "," Identifier "=" Type |
| ; |
| |
| ConstantDefs : Identifier "=" Expression |
| | ConstantDefs "," Identifier "=" Expression |
| ; |
| |
| AlgVarsDefs : Identifier |
| | Identifier "=" Expression |
| | AlgVarsDefs "," Identifier |
| | AlgVarsDefs "," Identifier "=" Expression |
| ; |
| |
| FuncParams : "(" ")" |
| | "(" FuncParamDecls ")" |
| ; |
| |
| FuncParamDecls : Type Identifiers |
| | FuncParamDecls ";" Type Identifiers |
| ; |
| |
| FuncBody : FuncVarDecls FuncStatements "end" |
| | StringToken ";" |
| ; |
| |
| FuncVarDecls : /* empty */ |
| | FuncVarDecls Type FuncVarDecl ";" |
| ; |
| |
| FuncVarDecl : Identifier |
| | Identifier "=" Expression |
| | FuncVarDecl "," Identifier |
| | FuncVarDecl "," Identifier "=" Expression |
| ; |
| |
| FuncStatements : FuncStatement |
| | FuncStatements FuncStatement |
| ; |
| |
| FuncStatement : Addressables ":=" Expressions ";" |
| | "if" Expressions ":" FuncStatements |
| OptElifFuncStats OptElseFuncStat "end" |
| | "while" Expressions ":" FuncStatements "end" |
| | "break" ";" |
| | "continue" ";" |
| | "return" Expressions ";" |
| ; |
| |
| OptElifFuncStats : /* empty */ |
| | OptElifFuncStats "elif" Expressions ":" FuncStatements |
| ; |
| |
| OptElseFuncStat : /* empty */ |
| | "else" FuncStatements |
| ; |
| |
| Events : Name |
| | Events "," Name |
| ; |
| |
| CoreEdge : EdgeEvents OptEdgeGuard OptEdgeUrgent OptEdgeUpdate |
| | "when" Expressions OptEdgeUrgent OptEdgeUpdate |
| | "now" OptEdgeUpdate |
| | "do" Updates |
| ; |
| |
| OptEdgeGuard : /* empty */ |
| | "when" Expressions |
| ; |
| |
| OptEdgeUrgent : /* empty */ |
| | "now" |
| ; |
| |
| OptEdgeUpdate : /* empty */ |
| | "do" Updates |
| ; |
| |
| EdgeEvents : EdgeEvent |
| | EdgeEvents "," EdgeEvent |
| ; |
| |
| EdgeEvent : "tau" |
| | Name |
| | Name "!" |
| | Name "!" Expression |
| | Name "?" |
| ; |
| |
| Locations : Location |
| | Locations Location |
| ; |
| |
| Location : "location" ";" |
| | "location" Identifier ";" |
| | "location" ":" LocationElements |
| | "location" Identifier ":" LocationElements |
| ; |
| |
| LocationElements : LocationElement |
| | LocationElements LocationElement |
| ; |
| |
| LocationElement : "initial" ";" |
| | "initial" Expressions ";" |
| | InvariantDecls |
| | "equation" Equations ";" |
| | "marked" ";" |
| | "marked" Expressions ";" |
| | "urgent" ";" |
| | "edge" CoreEdge ";" |
| | "edge" CoreEdge "goto" Identifier ";" |
| ; |
| |
| ActualParms : "(" ")" |
| | "(" Expressions ")" |
| ; |
| |
| FormalParms : "(" ")" |
| | "(" FormalDecls ")" |
| ; |
| |
| FormalDecls : FormalDeclaration |
| | FormalDecls ";" FormalDeclaration |
| ; |
| |
| FormalDeclaration : OptControllability "event" EventParamIds |
| | OptControllability "event" EventType EventParamIds |
| | Controllability EventParamIds |
| | Controllability EventType EventParamIds |
| | Name Identifiers |
| | "location" Identifiers |
| | "alg" Type Identifiers |
| ; |
| |
| EventParamIds : EventParamId |
| | EventParamIds "," EventParamId |
| ; |
| |
| EventParamId : Identifier OptEventParamFlags |
| ; |
| |
| OptEventParamFlags : /* empty */ |
| | OptEventParamFlags EventParamFlag |
| ; |
| |
| EventParamFlag : "!" |
| | "?" |
| | "~" |
| ; |
| |
| DiscDecls : DiscDecl |
| | DiscDecls "," DiscDecl |
| ; |
| |
| DiscDecl : Identifier |
| | Identifier "in" "any" |
| | Identifier "=" Expression |
| | Identifier "in" "{" Expressions "}" |
| ; |
| |
| ContDecls : ContDecl |
| | ContDecls "," ContDecl |
| ; |
| |
| ContDecl : Identifier OptDerivative |
| | Identifier "=" Expression OptDerivative |
| ; |
| |
| OptDerivative : /* empty */ |
| | "der" Expression |
| ; |
| |
| Equations : Equation |
| | Equations "," Equation |
| ; |
| |
| Equation : Identifier "'" "=" Expression |
| | Identifier "=" Expression |
| ; |
| |
| InvariantDecls : OptSupKind "invariant" Invariants ";" |
| | SupKind Invariants ";" |
| ; |
| |
| Invariants : Invariant |
| | Invariants "," Invariant |
| ; |
| |
| Invariant : Expression |
| | Name "needs" Expression |
| | NonEmptySetExpression "needs" Expression |
| | Expression "disables" Name |
| | Expression "disables" NamesSet |
| ; |
| |
| NamesSet : "{" Names "}" |
| ; |
| |
| Names : Name |
| | Names "," Name |
| ; |
| |
| Updates : Update |
| | Updates "," Update |
| ; |
| |
| Update : Addressable ":=" Expression |
| | "if" Expressions ":" Updates |
| OptElifUpdates OptElseUpdate "end" |
| ; |
| |
| Addressables : Addressable |
| | Addressables "," Addressable |
| ; |
| |
| Addressable : Identifier |
| | Identifier Projections |
| | "(" Addressable "," Addressables ")" |
| ; |
| |
| Projections : Projection |
| | Projections Projection |
| ; |
| |
| Projection : "[" Expression "]" |
| ; |
| |
| OptElifUpdates : /* empty */ |
| | OptElifUpdates "elif" Expressions ":" Updates |
| ; |
| |
| OptElseUpdate : /* empty */ |
| | "else" Updates |
| ; |
| |
| Identifiers : Identifier |
| | Identifiers "," Identifier |
| ; |
| |
| OptSupKind : /* empty */ |
| | SupKind |
| ; |
| |
| OptControllability : /* empty */ |
| | Controllability |
| ; |
| |
| Controllability : "controllable" |
| | "uncontrollable" |
| ; |
| |
| /////////////////////////////////////////////////////////////////////////////// |
| |
| OptIoDecls : /* empty */ |
| | OptIoDecls IoDecl |
| ; |
| |
| IoDecl : SvgFile |
| | SvgCopy |
| | SvgMove |
| | SvgOut |
| | SvgIn |
| | PrintFile |
| | Print |
| ; |
| |
| SvgFile : "svgfile" StringToken ";" |
| ; |
| |
| OptSvgFile : /* empty */ |
| | "file" StringToken |
| ; |
| |
| SvgCopy : "svgcopy" "id" Expression OptSvgCopyPre OptSvgCopyPost OptSvgFile ";" |
| ; |
| |
| OptSvgCopyPre : /* empty */ |
| | "pre" Expression |
| ; |
| |
| OptSvgCopyPost : /* empty */ |
| | "post" Expression |
| ; |
| |
| SvgMove : "svgmove" "id" Expression "to" Expression "," Expression |
| OptSvgFile ";" |
| ; |
| |
| SvgOut : "svgout" "id" Expression SvgAttr "value" Expression OptSvgFile |
| ";" |
| ; |
| |
| SvgAttr : "attr" StringToken |
| | "text" |
| ; |
| |
| SvgIn : "svgin" "id" Expression "event" SvgInEvent OptSvgFile ";" |
| ; |
| |
| SvgInEvent : Name |
| | "if" Expression ":" Name OptSvgInEventElifs "else" Name "end" |
| | "if" Expression ":" Name SvgInEventElifs "end" |
| ; |
| |
| OptSvgInEventElifs : /* empty */ |
| | SvgInEventElifs |
| ; |
| |
| SvgInEventElifs : "elif" Expression ":" Name |
| | SvgInEventElifs "elif" Expression ":" Name |
| ; |
| |
| PrintFile : "printfile" StringToken ";" |
| ; |
| |
| Print : "print" PrintTxt OptPrintFors OptPrintWhen OptPrintFile ";" |
| ; |
| |
| PrintTxt : Expression |
| | "pre" Expression |
| | "post" Expression |
| | "pre" Expression "post" Expression |
| ; |
| |
| OptPrintFors : /* empty */ |
| | "for" PrintFors |
| ; |
| |
| PrintFors : PrintFor |
| | PrintFors "," PrintFor |
| ; |
| |
| PrintFor : "event" |
| | "time" |
| | Name |
| | "initial" |
| | "final" |
| ; |
| |
| OptPrintWhen : /* empty */ |
| | "when" Expression |
| | "when" "pre" Expression |
| | "when" "post" Expression |
| | "when" "pre" Expression "post" Expression |
| ; |
| |
| OptPrintFile : /* empty */ |
| | "file" StringToken |
| ; |
| |
| /////////////////////////////////////////////////////////////////////////////// |
| |
| Types : Type |
| | Types "," Type |
| ; |
| |
| EventType : "void" |
| | Type |
| ; |
| |
| Type : "bool" |
| | "int" |
| | "int" "[" Expression ".." Expression "]" |
| | "real" |
| | "string" |
| | "list" Type |
| | "list" "[" Expression "]" Type |
| | "list" "[" Expression ".." Expression "]" Type |
| | "set" Type |
| | "dict" "(" Type ":" Type ")" |
| | "tuple" "(" Fields ")" |
| | "func" Type "(" ")" |
| | "func" Type "(" Types ")" |
| | "dist" Type |
| | Name |
| ; |
| |
| Fields : Field |
| | Fields ";" Field |
| ; |
| |
| Field : Type Identifiers |
| ; |
| |
| /////////////////////////////////////////////////////////////////////////////// |
| |
| Expressions : Expression |
| | Expressions "," Expression |
| ; |
| |
| OptExpression : /* empty */ |
| | Expression |
| ; |
| |
| Expression : OrExpression |
| | OrExpression "=>" OrExpression |
| | OrExpression "<=>" OrExpression |
| ; |
| |
| OrExpression : AndExpression |
| | OrExpression "or" AndExpression |
| ; |
| |
| AndExpression : CompareExpression |
| | AndExpression "and" CompareExpression |
| ; |
| |
| CompareExpression : AddExpression |
| | CompareExpression "<" AddExpression |
| | CompareExpression "<=" AddExpression |
| | CompareExpression "=" AddExpression |
| | CompareExpression "!=" AddExpression |
| | CompareExpression ">=" AddExpression |
| | CompareExpression ">" AddExpression |
| | CompareExpression "in" AddExpression |
| | CompareExpression "sub" AddExpression |
| ; |
| |
| AddExpression : MulExpression |
| | AddExpression "+" MulExpression |
| | AddExpression "-" MulExpression |
| ; |
| |
| MulExpression : UnaryExpression |
| | MulExpression "*" UnaryExpression |
| | MulExpression "/" UnaryExpression |
| | MulExpression "div" UnaryExpression |
| | MulExpression "mod" UnaryExpression |
| ; |
| |
| UnaryExpression : FuncExpression |
| | "-" UnaryExpression |
| | "+" UnaryExpression |
| | "not" UnaryExpression |
| | "sample" FuncExpression |
| ; |
| |
| FuncExpression : ExpressionFactor |
| | FuncExpression "[" Expression "]" |
| | FuncExpression |
| "[" OptExpression ":" OptExpression "]" |
| | FuncExpression "(" ")" |
| | FuncExpression "(" Expressions ")" |
| | StdLibFunction "(" ")" |
| | StdLibFunction "(" Expressions ")" |
| ; |
| |
| ExpressionFactor : "true" |
| | "false" |
| | NUMBERTK |
| | REALTK |
| | StringToken |
| | "time" |
| | "[" "]" |
| | "[" Expressions "]" |
| | "{" "}" |
| | NonEmptySetExpression |
| | "{" DictPairs "}" |
| | "(" Expression "," Expressions ")" |
| | "<" Type ">" ExpressionFactor |
| | "if" Expressions ":" Expression |
| OptElifExprs "else" Expression "end" |
| | "switch" Expression ":" SwitchBody "end" |
| | "(" Expression ")" |
| | Name |
| | Name "'" |
| | "?" |
| | "self" |
| ; |
| |
| NonEmptySetExpression : "{" Expressions "}" |
| ; |
| |
| DictPairs : Expression ":" Expression |
| | DictPairs "," Expression ":" Expression |
| ; |
| |
| OptElifExprs : /* empty */ |
| | OptElifExprs "elif" Expressions ":" Expression |
| ; |
| |
| SwitchBody : SwitchCases |
| | SwitchCases "else" Expression |
| | "else" Expression |
| ; |
| |
| SwitchCases : "case" Expression ":" Expression |
| | SwitchCases "case" Expression ":" Expression |
| ; |
| |
| Name : Identifier |
| | RELATIVENAMETK |
| | ABSOLUTENAMETK |
| | ROOTNAMETK |
| ; |
| |
| SupKind : "plant" |
| | "requirement" |
| | "supervisor" |
| ; |
| |
| StdLibFunction : "acosh" |
| | "acos" |
| | "asinh" |
| | "asin" |
| | "atanh" |
| | "atan" |
| | "cosh" |
| | "cos" |
| | "sinh" |
| | "sin" |
| | "tanh" |
| | "tan" |
| | "abs" |
| | "cbrt" |
| | "ceil" |
| | "del" |
| | "empty" |
| | "exp" |
| | "floor" |
| | "fmt" |
| | "ln" |
| | "log" |
| | "max" |
| | "min" |
| | "pop" |
| | "pow" |
| | "round" |
| | "scale" |
| | "sign" |
| | "size" |
| | "sqrt" |
| | "bernoulli" |
| | "beta" |
| | "binomial" |
| | "constant" |
| | "erlang" |
| | "exponential" |
| | "gamma" |
| | "geometric" |
| | "lognormal" |
| | "normal" |
| | "poisson" |
| | "random" |
| | "triangle" |
| | "uniform" |
| | "weibull" |
| ;</code></pre> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="tools-chapter-index">Tools</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>Below you can find information about the individual applications of the CIF toolset.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Applications</strong></p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF toolset consists of applications that cover a wide range of |
| functionality. The available applications are listed below, categorized by the |
| different phases of the development process.</p> |
| </div> |
| <div class="paragraph"> |
| <p><em>Specification</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-chapter-text-editor">CIF text editor</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-cif2yed">CIF to yEd transformer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><em>Supervisory controller synthesis</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-chapter-datasynth">Data-based supervisory controller synthesis</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-index">Event-based synthesis toolset</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-cif2supremica">CIF to Supremica transformer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><em>Simulation, validation, and visualization</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-index">CIF simulator</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><em>Verification</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-chapter-cif2mcrl2">CIF to mCRL2 transformer</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-cif2uppaal">CIF to UPPAAL transformer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><em>Real-time testing, code generation, and implementation</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-codegen-chapter-index">CIF code generator</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2plc-chapter-index">CIF PLC code generator</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><em>Miscellaneous</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-index">CIF to CIF transformer</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-mergecif">CIF merger</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-event-disabler">CIF event disabler</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-chapter-cif-explorer">CIF explorer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Scripting</strong></p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF tools can be used on the command line, as well as in the |
| Eclipse IDE. They can also be used in ToolDef scripts. The following additional |
| information is available on scripting related to CIF and ToolDef scripts:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-scripting-chapter-intro">Introduction to scripting</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-scripting-chapter-tools">Overview of scriptable tools</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-specification-tools">Specification tools</h3> |
| <div class="sect3"> |
| <h4 id="tools-chapter-text-editor">CIF text editor</h4> |
| <div class="paragraph"> |
| <p> |
| Part of the CIF tooling is a textual editor for CIF specifications. This |
| editor is part of the Eclipse IDE. Below is a list of some of the more |
| notable features of this text editor:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>continuous background validation (integrated parsing and type checking), with |
| error markings directly in the source</p> |
| </li> |
| <li> |
| <p>comment spell checking</p> |
| </li> |
| <li> |
| <p>code folding</p> |
| </li> |
| <li> |
| <p>commands to comment/uncomment the (partially) selected line or lines</p> |
| </li> |
| <li> |
| <p>block selection mode</p> |
| </li> |
| <li> |
| <p>detection of external changes to files</p> |
| </li> |
| <li> |
| <p>shows line numbers</p> |
| </li> |
| <li> |
| <p>drag-and-drop editing</p> |
| </li> |
| <li> |
| <p>optionally can show whitespace characters</p> |
| </li> |
| <li> |
| <p>configurable tab key settings</p> |
| </li> |
| <li> |
| <p>automatic removal of trailing whitespace from all lines on save</p> |
| </li> |
| <li> |
| <p>automatic addition of a new line character at the end of the file on save, |
| if none is present (includes smart detection of the platform dependent new |
| line characters that are used in the file)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./screenshot_ide.png" alt="Screenshot CIF text editor"> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-cif2yed">CIF to yEd transformer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF to yEd transformer can be used to transform CIF specifications to |
| yEd diagrams. Several <a href="#tools-cif2yed-diagram-kinds">kinds of diagrams</a> |
| can be generated. These diagrams can be used to better understand the |
| specification, to communicate the specification to other, or to be included in |
| reports.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The |
| <a href="http://www.yworks.com/en/products/yfiles/yed/">yEd Graph Editor</a> |
| is an |
| application that can be used to view, create, edit, arrange, import and export |
| various kinds of diagrams. It is freely available and runs on Windows, Linux, |
| and Mac OS X.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The yEd diagrams are generated as |
| <a href="http://graphml.graphdrawing.org/">GraphML</a> |
| files (<code>*.graphml</code> files), using yEd specific extensions to specify the |
| graphical representation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <b class="menuref">Convert CIF to yEd diagram…​</b>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <b class="menuref">Convert CIF to yEd diagram…​</b>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2yed</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2yed</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2yed-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative local file system path to the |
| output yEd/GraphML diagram file. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>.kind.graphml</code> file extension is added. For the added default file |
| extension, <code>kind</code> is replaced by the diagram kind (see other option), e.g. |
| <code>model</code>, resulting in file extension <code>.model.graphml</code>. If multiple |
| diagrams are generated, the output file path may not be specified. In such |
| cases, either use the implicit/default file names, or generate one diagram at |
| a time, allowing you to specify an explicit output file path for each of |
| them.</p> |
| </li> |
| <li> |
| <p><em>Diagram kinds</em>: The kinds of diagrams to generate. The default is to |
| generate all the different kinds of diagrams. See the |
| <a href="#tools-cif2yed-diagram-kinds">Diagram kinds</a> section for details.</p> |
| </li> |
| <li> |
| <p><em>Syntax highlighting</em>: Whether to apply syntax highlighting (if option is |
| enabled), or use plain text (if option is disabled). By default, syntax |
| highlighting is enabled. For large diagrams, disabling syntax highlighting |
| can significantly improve the performance, when displaying the diagrams in |
| yEd.</p> |
| </li> |
| <li> |
| <p><em>Transparent edge labels</em>: Enable option to use a transparent background for |
| edge labels. Disable option to use a light gray background. By default, the |
| option is disabled (a light gray background is used). See the |
| <a href="#tools-cif2yed-layout">Layout</a> section below for further details.</p> |
| </li> |
| <li> |
| <p><em>Model filters</em>: The kinds of features to include in the diagram. Only |
| applies to model diagrams. See the <a href="#tools-cif2yed-diagram-model">Model diagram</a> section |
| for details.</p> |
| </li> |
| <li> |
| <p><em>Relations</em>: The kinds of relations to include in relations diagrams. The |
| default is to include all kinds of relations. See the |
| <a href="#tools-cif2yed-diagram-relations">Relations diagram</a> section for details.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>For <a href="#tools-cif2yed-diagram-model">model diagrams</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>This transformation supports all CIF specifications.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For <a href="#tools-cif2yed-diagram-relations">relations diagrams</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>CIF specifications with |
| <a href="#lang-tut-reuse2-aut-def-param-kinds-aut">component parameters</a> are not |
| supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2yed-diagram-kinds">Diagram kinds</h5> |
| <div class="paragraph"> |
| <p>Several types of diagrams can be created. They are each described below. Using |
| the <em>Diagram kinds</em> option (see the <a href="#tools-cif2yed-options">Options</a> section |
| above), generation of certain kind of diagrams can be enabled or disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the option dialog, each diagram kind can be enabled and disabled |
| individually, using a checkbox.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>-k</code> or <code>--diagram-kinds</code> option, the |
| names of the diagram kinds, as indicates for each diagram kind in the sections |
| below, should be used, separated by commas. By default, i.e. when the <code>-k</code> or |
| <code>--diagram-kinds</code> option is not used, diagrams are generated for all the |
| different kinds. As an example, consider <code>-k model</code> or |
| <code>--diagram-kinds=model</code>. Only a model diagram is generated, while all |
| other diagrams are not generated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The diagram kinds that are specified using the option replace the default |
| diagram kinds. However, it is also possible to specify additions and removals |
| relative to the default features, by prefixing features with a <code>+</code> or <code>-</code> |
| respectively. For instance, when using <code>-k -model</code> or |
| <code>--diagram-kinds=-model</code> the default diagrams are generated, except for the |
| model diagram (due to <code>-model</code>). Replacements (no prefix) may not be |
| combined with additions/removals (<code>+</code> or <code>-</code> prefix).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying a replacement diagram kind twice leads to a warning being printed to |
| the console. Adding a diagram kind that is already present or removing a |
| diagram kind that is not present, also leads to a warning being printed. |
| A warning is also printed to the console if all diagram kinds are disabled, and |
| thus no output is generated.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2yed-diagram-model">Model diagram</h6> |
| <div class="paragraph"> |
| <p>The option value to use on the command line, for this kind of diagrams, is |
| <code>model</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A diagram of the model itself, with all its details. That is, the diagram can |
| be used instead of the textual representation of the model, without loss of |
| details. Changes with respect to the textual representation include among |
| others elimination of <a href="#tut-reuse2-chapter-imports">imports</a>, and the loss |
| of comments and textual layout.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All components (<a href="#tut-basics-chapter-automata">automata</a>, |
| <a href="#tut-reuse2-chapter-groups">groups</a>, automaton |
| <a href="#tut-reuse2-chapter-aut-def-inst">instantiations</a>, and group |
| instantiations) and components |
| <a href="#tut-reuse2-chapter-aut-def-inst">definitions</a> (automata and group |
| definitions) are visualized in a hierarchical manner, as rectangles contained |
| in other rectangles. Automaton and group instantiations are grouped together |
| into a single node in the diagram. All of them can be closed (collapsed) and |
| opened (expanded) in yEd, allowing to hide unimportant details while focusing |
| on only a part of the diagram. The header of the component or component |
| definition is shown at the top of the rectangle, while for instantiations the |
| word <code>Instantiations</code> is used as header. For groups and group definitions an |
| italic font is used, while for automata, automaton definitions, and |
| automaton/group instantiations, a regular font is used. The background (of the |
| header) is colored as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_comp_header.png" alt="cif2yed color comp header"></span> |
| A component (group/automaton)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_def_header.png" alt="cif2yed color def header"></span> |
| A component definition (group/automaton definition)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_inst_header.png" alt="cif2yed color inst header"></span> |
| A component instantiation (group/automaton instantiation)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For instantiations, the complete instantiations are shown as code block in the |
| body of the rectangle.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the declarations (e.g. |
| <a href="#tut-data-chapter-discrete-variables">variables</a>), |
| <a href="#tut-data-chapter-stat-invariants">invariants</a>, I/O declarations (e.g. |
| <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">SVG declarations</a>), etc a block of |
| code is used. Code blocks use header and background colors that are distinct |
| from the colors used for components, component definitions, and component |
| instantiations:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_code_header.png" alt="cif2yed color code header"></span> |
| A code block (header)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_code_bg.png" alt="cif2yed color code bg"></span> |
| A code block (background)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For automata, the <a href="#lang-tut-basics-automata-location">locations</a> are |
| visualized as rectangles with rounded colors. Their names (if applicable), |
| invariants, equations, etc are shown as code in the rectangles. The |
| <a href="#tut-data-chapter-init-preds">initialization</a> of the location (if present |
| and not <code>false</code>) is visualized as an incoming arrow without source location, |
| with a label indicating the initialization predicates if they are not <code>true</code>. |
| <a href="#lang-tut-basics-edge">Edges</a> are visualized as arrows between locations, |
| with arrows to the source location itself for self loop edges. The events, |
| guards, <code>now</code> keywords (for <a href="#tut-time-chapter-urgency">urgent</a> edges), |
| and updates are put as labels on the edges. Locations use a background color |
| that is distinct from the colors used for components, component definitions, |
| and code blocks:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_loc_bg.png" alt="cif2yed color loc bg"></span> |
| A location (background)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>As an example consider the following diagram of the CIF <code>tank</code> example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cif2yed/tank.model.layouted.png" alt="tank.model.layouted"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Using the <em>Model filters</em> option (see the <a href="#tools-cif2yed-options">Options</a> section |
| above), certain features of the model can be included or excluded from the |
| diagram. The table below indicates the features that can be enabled and |
| disabled using the option. The first column lists the names to use on the |
| command line. The second column indicates whether the feature is enabled |
| (included) by default. The third column describes what parts of the model are |
| included/excluded when the feature is enabled/disabled.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3334%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Name</th> |
| <th class="tableblock halign-left valign-top">Default</th> |
| <th class="tableblock halign-left valign-top">Description</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>io</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The I/O declarations, e.g. <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">SVG declarations</a>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>decls</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The declarations of the components. Includes the alphabet (if explicitly |
| specified) and monitors of the automata, event declarations, constant |
| declarations, variable declarations, function declarations, invariants, |
| initialization predicates, marker predicates, equations, etc.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>loc-decls</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The declarations of the locations. Includes the invariants, marker |
| predicates, equations, and urgency.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The guards of the edges. Includes also the urgency of the edge (the |
| <code>now</code>) keyword.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>updates</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The updates of the edges.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the features can be enabled and disabled |
| individually, using a checkbox.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>-f</code> or <code>--model-filters</code> option, the |
| names of the different features, as indicates in the first column of the table |
| above, should be used, separated by commas. The features indicated as default |
| in the second column of the table, are enabled when default settings are used, |
| i.e. when the <code>-f</code> or <code>--model-filters</code> option is not used. As an example, |
| consider <code>-f guards,updates</code> or <code>--model-filters=guards,updates</code>. Only |
| the guards and updates are included, while all the other features are excluded.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The features that are specified using the option replace the default features. |
| However, it is also possible to specify additions and removals relative to the |
| default features, by prefixing features with a <code>+</code> or <code>-</code> respectively. For |
| instance, when using <code>-f -loc-decls,+io</code> or |
| <code>--model-filters=-loc-decls,+io</code> the default features are used, with the |
| declarations of the locations disabled (due to <code>-loc-decls</code>), and with I/O |
| declarations enabled (due to <code>+io</code>). Replacements (no prefix) may not be |
| combined with additions/removals (<code>+</code> or <code>-</code> prefix).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying a replacement feature type twice leads to a warning being printed to |
| the console. Adding a feature that is already present or removing a feature |
| that is not present, also leads to a warning being printed.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2yed-diagram-relations">Relations diagram</h6> |
| <div class="paragraph"> |
| <p>The option value to use on the command line, for this kind of diagrams, is |
| <code>relations</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A diagram of only the <a href="#lang-tut-basics-automata-events">event</a> and |
| data relations. The diagram can be used to see which events are used by which |
| <a href="#tut-basics-chapter-automata">automata</a> (are in the |
| <a href="#tut-basics-chapter-alphabet">alphabet</a> of those automata). It can also be |
| used to see which data (variables, locations, etc) exist in the model and where |
| they are used. Furthermore, it can also be used to see how events and data are |
| passed via automaton and group |
| <a href="#tut-reuse2-chapter-aut-def-inst">instantiations</a>. Events, variables, and |
| locations can thereby potentially be renamed if the |
| <a href="#tut-reuse2-chapter-aut-def-params">parameters</a> of the |
| corresponding automaton or <a href="#tut-reuse2-chapter-groups">group</a> |
| <a href="#tut-reuse2-chapter-aut-def-inst">definitions</a> have different names than |
| the events, variables, and locations that are passed via the instantiations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All components (automata, groups, automaton instantiations, and group |
| instantiations) and component definitions (automaton and group definitions) are |
| visualized in a hierarchical manner, as rectangles contained in other |
| rectangles. Automaton and group instantiations are unfolded to their contents |
| (the body of the corresponding automaton or group definition). Essentially, it |
| is as if component definition/instantiation has been |
| <a href="#tools-cif2cif-chapter-elim-comp-def-inst">eliminated</a>, but the parameters are |
| kept. Within components and component definition bodies, the components |
| (including the component instantiations) and declarations (event declarations, |
| event parameters, algebraic variables, algebraic parameters, locations, etc) |
| are separated from the component definitions, using additional wrapping boxes. |
| Such wrapping boxes are only added if both components and component definitions |
| are present, and thus separation is needed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, all internal details of component instantiations are omitted, as they |
| can be seen in the graphical representations of component definitions (that are |
| instantiated by the instantiations). That is, only the external connections are |
| included, as they show the actual relations (definition here and use there, |
| synchronizations between components, etc). By excluding the internal details, |
| duplication is avoided for multiple instantiations of the same definition. All |
| empty components and components definitions are also excluded, as they only |
| clutter the diagram, and have no relations whatsoever.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All components can be closed (collapsed) and opened (expanded) in yEd, allowing |
| to hide unimportant details while focusing on only a part of the diagram. By |
| default, all components are closed (collapsed). This allows seeing the top |
| level structure. By selectively opening (expanding) components, more details |
| can be shown. It is also possible to focus on a single component, to show only |
| that component and its contents, by selecting |
| <span class="menuseq"><b class="menu">Grouping</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">View Group Content</b></span> |
| in yEd, while a closed or |
| opened component is selected.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The header of the component is shown at the top of the rectangle. It includes |
| the name of the component or component definition, whether it is a group or |
| automaton, whether it is a definition or not, etc. The parameters of component |
| definitions, and the arguments of component instantiations, are all omitted |
| from the headers. For wrappers either <em>Components</em> or <em>Component definitions</em> |
| is used as header text. For groups, group definitions, and group instantiations |
| an italic font is used, while for automata, automaton definitions, automaton |
| instantiations, and wrapping boxes, a regular font is used. The background of |
| the header is colored as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_comp_header.png" alt="cif2yed color comp header"></span> |
| A component (group/automaton)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_def_header.png" alt="cif2yed color def header"></span> |
| A component definition (group/automaton definition)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_inst_header.png" alt="cif2yed color inst header"></span> |
| A component instantiation (group/automaton instantiation)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_color_wrap_box_header.png" alt="cif2yed color wrap box header"></span> |
| A wrapping box for components (incl. instantiations) or component definitions</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Event <a href="#lang-tut-basics-automata-events">declarations</a>, |
| <a href="#tut-data-chapter-discrete-variables">discrete variables</a>, |
| <a href="#tut-time-chapter-continuous-variables">continuous variables</a>, |
| <a href="#tut-reuse1-chapter-algebraic-variables">algebraic variables</a>, |
| <a href="#tut-reuse2-chapter-input-variables">input variables</a>, and |
| <a href="#lang-tut-basics-automata-location">locations</a> are all visualized as |
| rectangles with a thick border. The text in the rectangle is a keyword |
| (<code>event</code>, <code>disc</code>, <code>cont</code>, etc), followed by the name of the declaration. |
| For <a href="#tut-channels-chapter-intro">channels</a> (events with a data type), the |
| name is followed by <code>!?~</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Event, location, and algebraic |
| <a href="#tut-reuse2-chapter-aut-def-params">parameters</a> are visualized as |
| octagons with a thin dashed border. The text in the rectangle is a keyword |
| (<code>event</code>, <code>location</code>, etc), followed by the name of the parameter. For |
| <a href="#tut-channels-chapter-intro">channels</a> (events with a data type), the name |
| is followed by the <a href="#lang-tut-reuse2-aut-def-param-kinds-event-restrictions">event parameter usage restriction flags</a> (e.g. <code>!</code> for send, |
| <code>?</code> for receive, and/or <code>~</code> for synchronization). For channel parameters |
| without flags, <code>!?~</code> is used as text after the name of the parameter.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Uses of events and data are visualized as circles. For uses of events by |
| automata (event in the alphabet of the automaton), the circles indicate the |
| type of use: <code>!</code> if the automaton sends over the channel, <code>?</code> if the |
| automaton receives over the channel, and no text if the automaton |
| <a href="#tut-basics-chapter-synchronizing-events">synchronizes</a> over the event (the |
| event is in the alphabet of the automaton). For data uses, the circles never |
| contain text.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Different colors are used for declarations, parameters, and uses, as well as |
| for events and data:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_event_decl.png" alt="cif2yed event decl"></span> |
| An event declaration</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_event_param.png" alt="cif2yed event param"></span> |
| An event parameter</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_event_usage_send.png" alt="cif2yed event usage send"></span> |
| An event usage (automaton sends)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_event_usage_recv.png" alt="cif2yed event usage recv"></span> |
| An event usage (automaton receives)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_event_usage_sync.png" alt="cif2yed event usage sync"></span> |
| An event usage (automaton synchronizes)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_data_decl.png" alt="cif2yed data decl"></span> |
| A variable declaration or a location</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_data_param.png" alt="cif2yed data param"></span> |
| A location parameter or an algebraic parameter</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2yed/cif2yed_data_usage.png" alt="cif2yed data usage"></span> |
| A data (variable, location, parameter) usage in a component</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Each event usage is coupled to the event declaration or event parameter that it |
| refers to, using a directed or undirected edge. For synchronizing usage an |
| undirected edge is used, for send usage a directed edge from the usage to the |
| event declaration or event parameter is used, and for receive usage a directed |
| edge from the event declaration or event parameter to the usage is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Each data usage in a component not related to a declaration (variable, |
| location, or parameter) gets a circular node to indicate usage. It is coupled |
| to the declaration it uses, via a directed edge from the declaration to the |
| use, to indicate the flow of data. Duplicate edges are avoided.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Event parameters of component instantiations are coupled to the actual event |
| (or event parameter) that is provided by the instantiation, using a directed or |
| undirected edge. If the parameter is a channel parameter that explicitly allows |
| sending (has a <code>!</code> flag) and doesn’t allow receiving (has no <code>?</code> flag), a |
| directed edge from the parameter to the actual event is used. If it explicitly |
| allows receiving (has <code>?</code> flag) and doesn’t allow sending (has no <code>!</code> |
| flag), a directed edge from the actual event to the parameter is used. If it |
| explicitly allows both sending and receiving (has both a <code>!</code> and a <code>?</code> |
| flag), a bidirectional edge is used. In all other cases, an undirected edge is |
| used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Location parameters of component instantiations are coupled to the actual |
| location (or location parameter) that is provided by the instantiation, using a |
| directed edge from the actual location to the parameter, to indicate the flow |
| of data. Similarly, algebraic parameters are related to the actual arguments. |
| However, for algebraic parameters, an |
| <a href="#tut-values-chapter-types-values-exprs">expression</a> may be provided. For |
| each variable, location, and parameter used in the actual argument, a directed |
| edge is added. Duplicate edges are avoided.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From declarations (variables, locations, parameters), directed edges are |
| included in the diagram for all relations to other declarations. For instance, |
| if a discrete variable is initialized using the value of an algebraic variable, |
| there will be an edge from the algebraic variable to the discrete variable. |
| Similarly, if in a continuous variable is used in a guard, there will be an |
| edge from the continuous variable to the location that contains the edge. |
| Duplicate edges are avoided.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example consider the following relations diagram of the CIF |
| 'machine/buffer' example, showing only the event relations:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cif2yed/machine_buffer.events.layouted.png" alt="machine buffer.events.layouted"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Using the <em>Relations</em> option (see the <a href="#tools-cif2yed-options">Options</a> section |
| above), certain kinds of relations included or excluded from the diagram. By |
| default all kinds of relations are included. The following kinds of relations |
| are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>event relations (<code>event</code>)</p> |
| </li> |
| <li> |
| <p>data relations (<code>data</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the features can be enabled and disabled |
| individually, using a checkbox.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>-r</code> or <code>--relations</code> option, the |
| names of the different kinds of relations, as indicates between parentheses |
| above, should be used, separated by commas. As an example, consider |
| <code>-r event</code> or <code>--relations=event</code>. Only the event relations are included, |
| while all the other relations are excluded.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The kinds that are specified using the option replace the default kinds. |
| However, it is also possible to specify additions and removals relative to the |
| default kinds, by prefixing names with a <code>+</code> or <code>-</code> respectively. For |
| instance, when using <code>-r -event</code> or <code>--relations=-event</code> the default kinds |
| are used, with the event relations excluded (due to <code>-event</code>). Replacements |
| (no prefix) may not be combined with additions/removals (<code>+</code> or <code>-</code> |
| prefix).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying a replacement kind type twice leads to a warning being printed to |
| the console. Adding a kind that is already present or removing a kind that is |
| not present, also leads to a warning being printed. Finally, generating a |
| relations diagram without any relations also leads to a warning being printed.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2yed-layout">Layout</h5> |
| <div class="paragraph"> |
| <p>The generated diagrams can be opened in the yEd Diagram Editor using |
| <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Open…​</b></span>. After opening the diagram, all nodes |
| overlap, as the generated diagrams don’t contain any positions for them. yEd |
| can automatically layout the diagram. Several layout algorithms are available |
| in the |
| <b class="menuref">Layout</b> |
| menu.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Good results for <a href="#tools-cif2yed-diagram-model">model diagrams</a> can often |
| be obtained by using the |
| <b class="button">Orthogonal layout</b>. |
| Select |
| <span class="menuseq"><b class="menu">Layout</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Orthogonal</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Classic</b></span> to show the |
| 'Orthogonal Layout' window. Click the |
| <b class="button">Dock</b> |
| button to dock |
| the window. Once docked, select |
| <b class="button">Integrated</b> |
| for |
| <b class="button">Edge Labeling</b> |
| and |
| <b class="button">Free</b> |
| for |
| <b class="button">Edge Label Model</b>. |
| Also enable the |
| <b class="button">Length Reduction</b> |
| and |
| <b class="button">Consider Node Labels</b> |
| options. Press the |
| <b class="button">Apply changes</b> |
| button (the green rectangle) at the top of the docked window to apply the |
| changes to the layout.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You may want to try different values for the 'Grid' option, to get |
| more or less spacing between nodes. Once you change a value, just apply the new |
| layout, as before. The automatic layout algorithms aren’t perfect, but they are |
| usually a good starting point.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, edge labels have a light gray background. This makes them easier |
| to read when placed on the edges. By changing the 'Edge Label Model' from |
| 'Free' to 'Side Slider' , labels are not placed on the |
| edges, but besides them. However, this often leads to some overlap, requiring |
| manual layouting. If the 'Side Slider' variant is used, you may want |
| to change the background of the edge labels to be transparent. This can be |
| achieved by enabling the <em>Transparent edge labels</em> option (see the |
| <a href="#tools-cif2yed-options">Options</a> section above).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Good results for <a href="#tools-cif2yed-diagram-relations">relations diagrams</a> |
| can often be obtained using the 'One-Click Layout' functionality of |
| yEd. Select <span class="menuseq"><b class="menu">Layout</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">One-Click Layout</b></span> or use the |
| corresponding toolbar button. This option is only available in yEd 3.14 or |
| newer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You can also close (collapse) and open (expand) groups and apply the layout |
| again.</p> |
| </div> |
| <div class="paragraph"> |
| <p>yEd has many more options. You can explore them using the included help text, |
| by selecting <span class="menuseq"><b class="menu">Help</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Help</b></span>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-structure-view">Structure View</h5> |
| <div class="paragraph"> |
| <p>yEd has a <em>Structure View</em> window that can be enabled via |
| <span class="menuseq"><b class="menu">Windows</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Structure View</b></span>. The <em>Structure View</em> can be used |
| to see and navigate the structure of the CIF model. By switching from |
| 'Text' to 'Description' (see upper right corner of the |
| <em>Structure View</em> window), useful descriptions are shown for all elements. |
| Furthermore, switching also ensures that the HTML code that is used for syntax |
| highlighting is not shown in the <em>Structure Viewer</em> (if syntax highlighting is |
| enabled, see the <a href="#tools-cif2yed-options">Options</a> section above). The following |
| image shows the difference:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cif2yed/yed_structure_view.png" alt="yed structure view"> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-supervisory-controller-synthesis-tools">Supervisory controller synthesis tools</h3> |
| <div class="sect3"> |
| <h4 id="tools-chapter-datasynth">Data-based supervisory controller synthesis</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The data-based supervisory controller synthesis tool performs data-based |
| supervisory controller synthesis, or simply data-based synthesis. It can be |
| used to <a href="#tut-extensions-chapter-synthesis">synthesize</a> a supervisor for an |
| untimed CIF specification, with data |
| (e.g. <a href="#tut-data-chapter-discrete-variables">discrete variables</a>). For a CIF |
| specification with plants and requirements, the tool computes a supervisor. |
| The supervisor restricts the plants in such a way that the resulting controlled |
| system satisfies the following properties:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The controlled system is safe. That is, all reachable states in the |
| controlled system satisfy the requirements.</p> |
| </li> |
| <li> |
| <p>The controlled system is controllable. That is, for all reachable states in |
| the controlled system, the |
| <a href="#lang-tut-extensions-synthesis-evtctrl">uncontrollable</a> events that are |
| enabled in the same state in the uncontrolled system are still possible in |
| the controlled system. In other words, uncontrollable events are not |
| restricted.</p> |
| </li> |
| <li> |
| <p>The controlled system is non-blocking. That is, it is possible to reach a |
| <a href="#lang-tut-extensions-synthesis-marked">marked</a> state from all reachable |
| states in the controlled system.</p> |
| </li> |
| <li> |
| <p>The controlled system is maximally permissive (or simply maximal). That is, |
| the controlled system permits all safe, controllable, and non-blocking |
| behaviors.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Note that <a href="#lang-tut-time-deadlock">deadlock</a> is not prevented for marked |
| states.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The synthesis algorithm is based on the following paper: Lucien Ouedraogo, |
| Ratnesh Kumar, Robi Malik, and Knut Ã…kesson: Nonblocking and Safe |
| Control of Discrete-Event Systems Modeled as Extended Finite Automata, IEEE |
| Transactions on Automation Science and Engineering, Volume 8, Issue 3, Pages |
| 560-569, July 2011.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-2">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply data-based synthesis…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply data-based synthesis…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifdatasynth</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifdatasynth</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application several other |
| options.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following options are part of the <em>Synthesis</em> category:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative local file system path to the |
| output CIF file. If not specified, defaults to the input file path, where the |
| <code>.cif</code> file extension is removed (if present), and a <code>.ctrlsys.cif</code> |
| file extension is added.</p> |
| </li> |
| <li> |
| <p><em>Supervisor name</em>: The name of the resulting supervisor automaton. If not |
| specified, it defaults to <code>sup</code>. For more information, see the section on |
| the <a href="#tools-datasynth-supervisor">resulting supervisor</a> below.</p> |
| </li> |
| <li> |
| <p><em>Supervisor namespace</em>: The namespace of the resulting supervisor. If not |
| specified, it defaults to the empty namespace. For more information, see the |
| section on <a href="#tools-datasynth-supervisor-namespace">namespaces</a> below.</p> |
| </li> |
| <li> |
| <p><em>Forward reachability</em>: Whether to perform forward reachability during |
| synthesis, or omit it. Is disabled by default. For more information, see the |
| section on <a href="#tools-datasynth-forward-reach">forward reachability</a> below.</p> |
| </li> |
| <li> |
| <p><em>Statistics</em>: The kinds of statistics to print. By default, no statistics |
| are printed. For more information, see the section on |
| <a href="#tools-datasynth-stats">statistics</a> below.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Internally during synthesis, predicates are represented using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). There are |
| various options that can influence the use of BDDs. The following options are |
| part of the <em>BDD</em> sub-category of the <em>Synthesis</em> category:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>BDD output mode</em>: This option can be used to control how the BDDs are |
| converted to CIF for the output of synthesis. For more information, see the |
| <a href="#tools-datasynth-supervisor-bdd">BDD representation in CIF</a> section below.</p> |
| </li> |
| <li> |
| <p><em>BDD output name prefix</em>: The prefix to use for BDD related names in the |
| output. Only has an effect if the <em>BDD output mode</em> option is set to |
| represent the internal BDD nodes directly in CIF. The default prefix is |
| <code>bdd</code>. For more information, see the <a href="#tools-datasynth-supervisor-bdd">BDD representation in CIF</a> |
| section below.</p> |
| </li> |
| <li> |
| <p><em>BDD variable order</em>: CIF variables and automata are represented using one or |
| more boolean variables. The initial order of the boolean variables is |
| determined by this option. For more information, see the |
| <a href="#tools-datasynth-var-order">BDD variable order</a> section below.</p> |
| </li> |
| <li> |
| <p><em>BDD FORCE variable ordering algorithm</em>: CIF variables and automata are |
| represented using one or more boolean variables. The initial order of the |
| boolean variables can be improved by enabling this option. For more |
| information, see the <a href="#tools-datasynth-var-order">BDD variable order</a> section below.</p> |
| </li> |
| <li> |
| <p><em>BDD sliding window variable ordering algorithm</em>: CIF variables and automata |
| are represented using one or more boolean variables. The initial order of the |
| boolean variables can be improved by enabling this option. For more |
| information, see the <a href="#tools-datasynth-var-order">BDD variable order</a> section below.</p> |
| </li> |
| <li> |
| <p><em>BDD sliding window size</em>: The maximum length of the window to use for the |
| BDD sliding window variable ordering algorithm. This option only has effect |
| if the <em>BDD sliding window variable ordering algorithm</em> option is enabled. |
| The size must be an integer number in the range [1 .. 12]. The default size |
| is 4. For more information, see the <a href="#tools-datasynth-var-order">BDD variable order</a> section |
| below.</p> |
| </li> |
| <li> |
| <p><em>BDD predicate simplify</em>: Several BDD predicates may be simplified under the |
| assumption of other predicates, resulting in smaller/simpler output. This may |
| decrease the size of the resulting controller, and may give more insight. For |
| more information, see the <a href="#tools-datasynth-simplification">Simplification</a> section |
| below.</p> |
| </li> |
| <li> |
| <p><em>BDD library initial node table size</em>: The BDD library that is used maintains |
| an internal node table. This option can be used to set the initial size of |
| that node table. The size will automatically be increased during synthesis, |
| if necessary. Increasing the initial size can increase performance for large |
| systems, as it will not be necessary to repeatedly increase the size of the |
| node table. However, a larger node table requires more memory, and can lead |
| to the node table no longer fitting within CPU caches, degrading performance. |
| The default is <code>100000</code> nodes. The initial node table size must be in the |
| range [1 .. 2<sup>31</sup> - 1]. For more information, see the |
| <a href="#tools-datasynth-stats">Statistics</a> section.</p> |
| </li> |
| <li> |
| <p><em>BDD library operation cache size</em>: The BDD library that is used maintains |
| an internal operation cache. This option can be used to set the fixed size of |
| that cache. The operation cache size must be in the range |
| [2 .. 2<sup>31</sup> - 1]. By default, this option is disabled (value <code>off</code> on |
| the command line), and the <em>BDD library operation cache ratio</em> option is |
| used instead. For more information, see the <a href="#tools-datasynth-op-caches">BDD operation caches</a> |
| section below.</p> |
| </li> |
| <li> |
| <p><em>BDD library operation cache ratio</em>: The BDD library that is used maintains |
| an internal operation cache. This option can be used to set the ratio of the |
| size of the operation cache of the BDD library to the size of the node table |
| of the BDD library. For instance, a ratio of <code>0.1</code> means that the size of |
| the operation cache is 10% of the size of the node table. The operation cache |
| ratio must be in the range [0.01 .. 1000]. The default ratio is 1.0. This |
| option has no effect if the <em>BDD library operation cache size</em> option is |
| enabled. For more information, see the <a href="#tools-datasynth-op-caches">BDD operation caches</a> |
| section below.</p> |
| </li> |
| <li> |
| <p><em>BDD debug max nodes</em>: Internally, predicates are represented |
| using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). This option |
| control the maximum number of BDD nodes for which to convert a BDD to a |
| readable CNF/DNF representation for the debug output. The default is <code>10</code> |
| nodes. The maximum must be in the range [1 .. 2<sup>31</sup> - 1]. |
| The option |
| can be set to have an infinite maximum (no maximum), using option value |
| <code>inf</code>. For more information, see the <a href="#tools-datasynth-dbg-output">Debug output</a> |
| section below.</p> |
| </li> |
| <li> |
| <p><em>BDD debug max paths</em>: Internally, predicates are represented |
| using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). This option |
| control the maximum number of BDD true paths for which to convert a BDD to a |
| readable CNF/DNF representation for the debug output. The default is <code>10</code> |
| paths. The maximum must be in the range [0 .. 1.7e308]. The option |
| can be set to have an infinite maximum (no maximum), using option value |
| <code>inf</code>. For more information, see the <a href="#tools-datasynth-dbg-output">Debug output</a> |
| section below.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-2">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The data-based supervisory controller synthesis tool supports a subset of CIF |
| specifications. The following restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Only <code>plant</code> and <code>requirement</code> automata are supported. Automata with a |
| <code>supervisor</code> kind, as well as kindless/regular automata (without a |
| supervisory kind) are not supported.</p> |
| </li> |
| <li> |
| <p>Specifications without plant automata are not supported.</p> |
| </li> |
| <li> |
| <p>Events not declared as controllable or uncontrollable are not supported. |
| This includes the <code>tau</code> event, both explicitly used on edges, as well as |
| implicitly for edges without explicitly mentioned events.</p> |
| </li> |
| <li> |
| <p>The use of channels (events with data types) in requirements is not |
| supported. That is, requirements that send or receive (with or without data) |
| are not supported.</p> |
| </li> |
| <li> |
| <p>Regular invariants, plant invariants, and supervisor invariants are not |
| supported. Only requirement invariants are supported. To allow plant |
| state/event exclusion invariants to be used in the input, manually eliminate |
| them first using the <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> CIF to |
| CIF transformation.</p> |
| </li> |
| <li> |
| <p>Continuous variables are not supported.</p> |
| </li> |
| <li> |
| <p>Only discrete/input variables with a boolean type, ranged integer type |
| (e.g. <code>int[0..5]</code>), or enumeration type are supported. For integer types, |
| ranges that include negative integer values are not supported. For algebraic |
| variables and algebraic parameters of components, all types are supported.</p> |
| </li> |
| <li> |
| <p>Discrete variables must have supported initial values. If explicit initial |
| values are given, they must be supported predicates (for boolean variables) |
| or supported expressions as described below (for all other variables).</p> |
| </li> |
| <li> |
| <p>Automata with non-determinism for controllable events are not supported. |
| That is, automata that have locations with multiple outgoing edges for the |
| same controllable event, with overlapping guards (e.g. <code>x > 1</code> and |
| <code>x < 4</code>), are not supported. Note that this check is performed on the |
| <a href="#tools-cif2cif-chapter-linearize-product">linearized</a> guards, and may |
| therefore lead to false positives, as the check is an over-approximation and |
| guard overlap may be detected for unreachable states.</p> |
| </li> |
| <li> |
| <p>Conditional updates (<code>if</code> updates), multi-assignments, and partial variable |
| assignments are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only limited forms of predicates (for markers, invariants, initialization, |
| guards, etc) are supported. The supported predicates are:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Boolean literals (<code>true</code>, <code>false</code>).</p> |
| </li> |
| <li> |
| <p>Discrete/input/algebraic boolean variables (<code>x</code>, for <code>x</code> a discrete, |
| input, or algebraic variable with a boolean type).</p> |
| </li> |
| <li> |
| <p>Locations (<code>aut.loc</code>, for <code>aut</code> and automaton and <code>loc</code> a location of |
| that automaton).</p> |
| </li> |
| <li> |
| <p>The unary inverse operator (<code>not</code>) on a supported predicate.</p> |
| </li> |
| <li> |
| <p>The binary logical conjunction (<code>and</code>) on two supported predicates.</p> |
| </li> |
| <li> |
| <p>The binary logical disjunction (<code>or</code>) on two supported predicates.</p> |
| </li> |
| <li> |
| <p>The binary logical implication (<code>=></code>) on two supported predicates.</p> |
| </li> |
| <li> |
| <p>The binary logical bi-conditional (<code><=></code>) on two supported predicates.</p> |
| </li> |
| <li> |
| <p>The binary equality comparison (<code>=</code>) on two supported predicates, or on two |
| supported integer or enumeration expressions.</p> |
| </li> |
| <li> |
| <p>The binary inequality comparison (<code>!=</code>) on two supported predicates, or on |
| two supported integer or enumeration expressions.</p> |
| </li> |
| <li> |
| <p>The binary less than comparison (<code><</code>) on two supported integer expressions.</p> |
| </li> |
| <li> |
| <p>The binary less than or equal comparison (<code><=</code>) on two supported integer |
| expressions.</p> |
| </li> |
| <li> |
| <p>The binary greater than comparison (<code>></code>) on two supported integer |
| expressions.</p> |
| </li> |
| <li> |
| <p>The binary greater than or equal comparison (<code>>=</code>) on two supported integer |
| expressions.</p> |
| </li> |
| <li> |
| <p>Conditional expressions (<code>if</code> expressions) with supported guard and |
| resulting value predicates.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only limited forms of integer and enumeration expressions (for binary |
| comparisons, initial values of variables, right hand sides of assignments, etc) |
| are supported. The supported expressions are:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>A non-negative integer literal/value.</p> |
| </li> |
| <li> |
| <p>An enumeration literal/value.</p> |
| </li> |
| <li> |
| <p>Discrete/input/algebraic integer/enumeration variables (<code>x</code>, for <code>x</code> a |
| discrete, input, or algebraic variable with an integer or enumeration type).</p> |
| </li> |
| <li> |
| <p><code>+i</code> for <code>i</code> a supported integer expression.</p> |
| </li> |
| <li> |
| <p><code>i + j</code> for <code>i</code> and <code>j</code> supported integer expressions.</p> |
| </li> |
| <li> |
| <p><code>i div j</code> and <code>i mod j</code> for <code>i</code> a supported integer expressions, and |
| <code>j</code> a positive integer value, or a computation that results in a positive |
| integer value, as long as the computation is not too complex to be performed |
| statically. That is, <code>j</code> must essentially be constant.</p> |
| </li> |
| <li> |
| <p>Conditional expressions (<code>if</code> expressions) with supported guard predicates |
| and supported resulting values.</p> |
| </li> |
| <li> |
| <p>Any other valid CIF expression (computation) that that results in a |
| non-negative integer value or an enumeration value, as long as the |
| computation is not too complex to be performed statically. That is, the |
| computation must essentially represent a fixed/constant value.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples of computations that can be statically evaluated:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>true and false</code> (result is <code>false</code>)</p> |
| </li> |
| <li> |
| <p><code>c or false</code>, for a constant <code>c</code> with value <code>false</code> (result is |
| <code>false</code>)</p> |
| </li> |
| <li> |
| <p><code>1 + 1</code> (result is <code>2</code>)</p> |
| </li> |
| <li> |
| <p><code>2 * 5</code> (result is <code>10</code>)</p> |
| </li> |
| <li> |
| <p><code>floor(3.14)</code> (result is <code>3</code>)</p> |
| </li> |
| <li> |
| <p><code>c + 1</code>, for a constant <code>c</code> with value <code>2</code> (result is <code>3</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples of computations that can <em>not</em> be statically evaluated:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>v + 1</code>, for <code>v</code> a discrete variable. The computation results in |
| different values for different values of <code>v</code>.</p> |
| </li> |
| <li> |
| <p><code>v = true</code> for <code>v</code> a discrete variable. The computation results in |
| different values for different values of <code>v</code>.</p> |
| </li> |
| <li> |
| <p><code>v = e</code> for <code>v</code> a discrete variable and <code>e</code> an enumeration |
| literal/value. The computation results in different values for different |
| values of <code>v</code>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only limited forms of assignments are supported. The supported assignments are:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>xb := p</code></p> |
| </li> |
| <li> |
| <p><code>xi := ie</code></p> |
| </li> |
| <li> |
| <p><code>xi := ie - ie</code></p> |
| </li> |
| <li> |
| <p><code>xe := ee</code></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For the following constraints:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>xb</code> is a boolean variable.</p> |
| </li> |
| <li> |
| <p><code>xi</code> is a supported integer variable, as described above.</p> |
| </li> |
| <li> |
| <p><code>xe</code> is an enumeration variable.</p> |
| </li> |
| <li> |
| <p><code>p</code> is a supported predicate, as described above.</p> |
| </li> |
| <li> |
| <p><code>ie</code> is a supported integer expression, as described above.</p> |
| </li> |
| <li> |
| <p><code>ee</code> is a supported enumeration expression, as described above.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Additionally, the tool warns about state/event exclusion invariants for events |
| that are not in the alphabet of any automaton. Such invariants have no effect, |
| as they try to (further) restrict events that are never enabled to begin with.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-2">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be synthesized:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Additionally, the CIF specification is converted to an internal representation |
| on which the synthesis is performed. This conversion also applies |
| <a href="#tools-cif2cif-chapter-linearize-product">linearization (product variant)</a> to |
| the edges. Predicates are represented internally using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-requirements">Supported requirements</h5> |
| <div class="paragraph"> |
| <p>Three types of requirements are supported: |
| <a href="#tut-data-chapter-stat-invariants">state invariants</a>, |
| <a href="#tut-data-chapter-stat-evt-excl-invariants">state/event exclusion invariants</a>, and |
| <a href="#lang-tut-extensions-synthesis-autkind">requirement automata</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>State invariants are global conditions over the values of variables (and |
| locations of automata) that must always hold. Such requirements are sometimes |
| also called mutual state exclusions. Here are some examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">requirement invariant x != 0 and not p.b; |
| requirement invariant x > 5; |
| requirement invariant not(x = 1 and y = 1) or q.x = a; |
| |
| requirement (x = 1 and y = 1) or (x = 2 and y = 2); |
| requirement (3 <= x and x < = 5) or (2 <= y and y <= 7); |
| requirement x = 1 => y > 2;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>State/event exclusion invariants or simply state/event exclusions are |
| additional conditions under which transitions may take place for certain |
| events. Here are some examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">requirement invariant buffer.c_add needs buffer.count < 5; |
| requirement invariant buffer.c_remove needs buffer.count > 0; |
| requirement invariant button.on = 1 disables lamp.c_turn_on; |
| |
| requirement {lamp.c_turn_on, motor.c_turn_on} needs button.Off; |
| requirement p.x = 3 and p.y > 7 disables p.u_something;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Requirement automata are simply automata marked as <code>requirement</code>. They |
| usually introduce additional state by using multiple locations or a variable. |
| The additional state is used to be able to express the requirement. One common |
| example is a counter. For instance, consider the following requirement, which |
| prevents more than three products being added to a buffer:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">requirement automaton counter: |
| disc int[0..5] count = 0; |
| |
| requirement invariant count <= 3; |
| |
| location: |
| initial; |
| marked; |
| |
| edge buffer.c_add do count := count + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Another common example is a requirement that introduces ordering. For instance, |
| consider the following requirement, which states that <code>motor1</code> must always be |
| turned on before <code>motor2</code> is turned on, and they must always be turned off in |
| the opposite order:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">requirement automaton order: |
| location on1: |
| initial; |
| marked; |
| edge motor1.c_on goto on2; |
| |
| location on2: |
| edge motor2.c_on goto off2; |
| |
| location off2: |
| edge motor2.c_off goto off1; |
| |
| location off1: |
| edge motor1.c_off goto on1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Besides the explicit requirements, synthesis also prevents runtime errors. This |
| includes enforcing that integer variables stay within their range of allowed |
| values. This is essentially an implicit requirement. For instance, for a CIF |
| specification with a variable <code>x</code> of type <code>int[0..5]</code> and a variable <code>y</code> |
| of type <code>int[1..3]</code>, requirement invariant |
| <code>0 <= x and x <= 5 and 1 <= y and y <= 3</code> is |
| implicitly added and enforced by the synthesis algorithm. In the resulting |
| controlled system, no runtime errors due to variables being assigned values |
| outside their domain (integer value range) occur.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-supervisor">Resulting supervisor</h5> |
| <div class="paragraph"> |
| <p>If the supervisor has to restrict so much of the behavior of the uncontrolled |
| system that no initial state remains, the controlled system becomes empty. The |
| synthesis algorithm then ends with an <em>empty supervisor</em> error, and no output |
| CIF file is created.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If an initial state remains after synthesis, an output CIF file is created. The |
| contents is the controlled system. The controlled system is obtained by taking |
| the input specification, and modifying it. The requirement automata are changed |
| to supervisor automata. Some or all of the requirement invariants may be |
| <a href="#tools-cif2cif-chapter-remove-reqs">removed</a>, depending on the |
| <a href="#tools-datasynth-simplification">simplifications</a> that are applied. An |
| additional external supervisor automaton is added. Also, depending on the |
| simplifications that are applied, the requirement automata may serve as |
| <a href="#tut-data-chapter-monitoring">monitors</a> or <em>observers</em> for the external |
| supervisor, or may actually impose the requirement restrictions. An external |
| supervisor is a <code>supervisor</code> automaton that adds restrictions to the |
| uncontrolled system (the plants), and potentially the requirement automata, |
| depending on the simplifications that are applied. The supervisor uses the |
| same events as the plants, and refers to plant and requirement locations and |
| variables in its conditions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, the resulting external supervisor automaton is put in the empty |
| <a href="#tut-reuse2-chapter-namespaces">namespace</a>, at the top level of the |
| resulting specification. That is, the supervisor automaton is not put in any |
| groups. See the <a href="#tools-datasynth-supervisor-namespace">Namespace</a> section for more |
| information.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, the added supervisor automaton is named <code>sup</code>. Using the |
| <em>Supervisor name</em> option (see <a href="#tools-datasynth-options">options</a> section |
| above), it is possible to specify a different name. Custom supervisor automaton |
| names must be valid CIF identifiers, i.e. they may consist of letters, digits, |
| and underscores (<code>_</code>), but may not start with a digit. If the resulting |
| supervisor automaton has a name that conflicts with an existing declaration, it |
| is automatically renamed to have a non-conflicting name. In such cases, a |
| warning is printed to the console to inform the user.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting supervisor has exactly one self loop edge for each of the |
| controllable events in the alphabet of the controlled system (which is equal to |
| the alphabet of the uncontrolled system). These self loops represent the |
| possible conditions under which the supervisor allows the events to occur in |
| the controlled system. The exact predicates may vary, depending on the |
| <a href="#tools-datasynth-simplification">simplifications</a> that are applied.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting supervisor may have an initialization predicate that restricts |
| the states in which the system may be initialized (may start), on top of the |
| initialization constraints already present in the uncontrolled system. For more |
| information on this initialization predicate, see the section on |
| <a href="#tools-datasynth-init">initialization</a> below.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-datasynth-supervisor-namespace">Namespace</h6> |
| <div class="paragraph"> |
| <p>As indicated above, by default the resulting supervisor automaton is put in the |
| empty <a href="#tut-reuse2-chapter-namespaces">namespace</a>, at the top level of the |
| resulting specification. That is, the supervisor automaton is not put in any |
| groups.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is possible to add a namespace to the entire resulting specification. That |
| is, to put groups around the original plants and requirements, the added |
| supervisor automaton, etc. A namespace can be added using the |
| <em>Supervisor namespace</em> option (see <a href="#tools-datasynth-options">options</a> |
| section above). By default, no additional namespace is added.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By adding a namespace around the entire resulting specification, the synthesis |
| result can be easily <a href="#tools-chapter-mergecif">merged</a> with for instance a |
| simulation model. The added namespace ensures that there are no naming |
| conflicts between the plants of the simulation model and the similarly original |
| plants. The events are not put in the new namespace, but are instead kept in |
| their original place, wrapped in groups as necessary to keep their original |
| identities (absolute names). This ensures that it remains possible to connect |
| (merge) the events of the synthesis output with the events of the simulation |
| model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The namespace specified using the option, must consist of one or more valid CIF |
| identifiers, separated by dots (<code>.</code>). Valid CIF identifiers consist of one or |
| more letters, digits, and underscores (<code>_</code>), but may not start with a digit. |
| As an example, consider namespace <code>a.b</code>. A group <code>b</code> is wrapped around the |
| entire synthesis result, and a group <code>a</code> is wrapped around group <code>b</code>. Group |
| <code>a</code> is then the new synthesis result.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a part of the namespace has the same name as an event that remains in its |
| original place, this leads to a conflict, and synthesis fails. If the namespace |
| does not conflict, but is non-empty (it contains an event or it contains a |
| group that contains an event), synthesis also fails.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-datasynth-supervisor-bdd">BDD representation in CIF</h6> |
| <div class="paragraph"> |
| <p>Internally, predicates are represented using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). The supervisor |
| that is the output of synthesis, contains several predicates as well. For |
| instance, it has self loops with guard predicates, and it may have an |
| initialization predicate. The predicates represented as BDDs need to be |
| represented as CIF predicates. There are multiple approaches to do this, and |
| the <em>BDD output mode</em> option (see <a href="#tools-datasynth-options">options</a> |
| section above), can be used to configure the approach to use.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first approach, which is also the default approach (named <code>normal</code>), is |
| to use either |
| <a href="http://en.wikipedia.org/wiki/Conjunctive_normal_form">Conjunctive Normal Form</a> |
| (CNF) or |
| <a href="http://en.wikipedia.org/wiki/Disjunctive_normal_form">Disjunctive Normal Form</a> |
| (DNF) predicates. This |
| approach has as benefit that for relatively small predicates (usually for small |
| systems), the CIF predicates are often intuitive, and can easily understood. |
| The downside is that for larger systems, the CIF predicates often grow |
| exponentially in size.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second approached (named <code>nodes</code>), is to represent the internal BDD nodes |
| directly in CIF. The BDD is then more or less coded directly in CIF, using |
| some constants and algebraic variables, and is evaluated using a BDD evaluation |
| function. The benefit is that for larger systems, this representation remains |
| relatively small, and at the very least doesn’t blow up nearly as much as the |
| CNF and DNF representations. The downside to this approach, is that it leads to |
| a supervisor that can not be easily understood by inspecting it. For this |
| approach, several objects are created in the top level scope of the CIF |
| specification. The names of these declarations all share a common prefix. The |
| default prefix is <code>bdd</code>, but it can be changed using the |
| <em>BDD output name prefix</em> option (see |
| <a href="#tools-datasynth-options">options</a> section above). No existing |
| declarations, whose names start with that prefix, should be present in the top |
| level scope of the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-init">Initialization</h5> |
| <div class="paragraph"> |
| <p>The synthesis algorithm ensures that in the controlled system, the requirement |
| state invariants hold in all reachable states. It also ensures that in the |
| controlled system, for all transitions from reachable states, the events only |
| occur if the requirement automata and state/event exclusion invariants allow |
| them.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The synthesis algorithm does not restrict any uncontrollable events. Instead, |
| such restrictions are propagated backwards to the source state of the edge with |
| the uncontrollable event, and from there to the transitions that lead to the |
| source state, etc. They are propagated backwards until an edge with a |
| controllable event is encountered (for which the guard can be restricted) or |
| the initial state is reached (and the initialization predicate can be |
| restricted).</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a variable in the uncontrolled system has a single initial value, and the |
| initialization predicate is restricted to not allow this initial value, |
| initialization will be impossible, causing an <em>empty supervisor</em> error. For |
| discrete variables with |
| <a href="#lang-tut-data-discvar-init-multiple">multiple potential initial values</a>, |
| the synthesis algorithm may restrict initialization to disallow certain initial |
| values, while still leaving possibilities for initialization. For discrete |
| variables declared to initially have an |
| <a href="#lang-tut-data-discvar-init-any">arbitrary</a> initial value, as well as |
| for input variables, the synthesis algorithm essentially determines under which |
| conditions the system can be started, and still exhibits only safe, |
| non-blocking behavior.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the controlled system requires more strict initialization than the |
| uncontrolled system, an additional initialization predicate is added to the |
| resulting supervisor. The exact predicate may differ, depending on the |
| <a href="#tools-datasynth-simplification">simplifications</a> that are applied.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-forward-reach">Forward reachability</h5> |
| <div class="paragraph"> |
| <p>Synthesis essentially works by calculations that involve predicates that |
| partition the entire state space into states that satisfy a property or don’t |
| satisfy a property. For instance, a marker predicate may indicate which states |
| of the state space are marked. All other states are thus not marked.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| Calculations during synthesis often involve |
| <a href="https://en.wikipedia.org/wiki/Reachability">reachability</a>. |
| For instance, |
| from which states is it possible to reach a marker state? To compute the states |
| that can reach a marker state, the marker predicate of the input specification |
| is used. The marker predicate indicates the states that are themselves marked. |
| Then, the states are calculated that can reach one of those marked states, via |
| a single transition. They are put together, to form the states that are marked |
| or can be marked after one transition. By taking another such step, we can add |
| the states that can reach a marked state via two transitions. We then have all |
| states that can reach a marked state via zero, one, or two transitions. We can |
| repeat this until no new states are found, which is called reaching a |
| <a href="https://en.wikipedia.org/wiki/Fixed_point_%28mathematics%29">fixed point</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| This form of reachability is called backward reachability, as it starts with |
| some target (e.g. marked states), and goes backwards to find all states from |
| which the target can be reached. Backward reachability can lead to states that |
| could never be reached from an initial state, even in the uncontrolled system. |
| This leads to two separate issues.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first issue is about unintuitive resulting supervisor guards. The |
| resulting supervisor forbids certain transitions, by restricting controllable |
| events. It among others forbids transitions that end up in states from which no |
| marked state can be reached. However, if those forbidden states can never be |
| reached from an initial state, there is no reason to restrict the controllable |
| events in such cases. The guards of the resulting supervisor then appear to |
| restrict the controllable events, while in fact the guard doesn’t impose a |
| restriction for the controlled system. The supervisor simply doesn’t have the |
| necessary information to know this.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second issue is about performance. Expanding unreachable states during |
| backward reachability takes time and costs memory, while it has no useful |
| effect on the resulting controlled system.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The use of forward reachability can be a solution to both problems. Forward |
| reachability starts with the initial states, and adds states reachable via one |
| transitions, then via two transitions, then via three transitions, etc. This |
| is repeated until all reachable states are found.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By combining both forward and backward reachability, the supervisor knows about |
| states that exist in the uncontrolled system (due to forward reachability) and |
| about states that it should forbid (due to backward reachability). This leads |
| to the supervisor only restricting transitions that are strictly necessary. |
| However, both when using forward reachability and when not using it, the |
| synthesized supervisor is safe, non-blocking, and maximally permissive. It is |
| only the guards that are more complex than they might need to be, if forward |
| reachability is not used. More complex guards are often less readable, and |
| potentially more expensive to implement in an actual controller.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By combining both forward and backward reachability, parts of the state space |
| that are not relevant may not have to be expanded (as much), which may improve |
| performance. However, computing the forward reachability may also take time |
| and cost memory, thus reducing performance.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It depends on the specification being synthesized whether enabling forward |
| reachability increases or decreases performance. It also depends on the |
| specification whether there is any benefit to using forward reachability for |
| the guards of the supervisor. Forward reachability is disabled by default. It |
| can be enabled using the <em>Forward reachability</em> option (see |
| <a href="#tools-datasynth-options">options</a> section above).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-simplification">Simplification</h5> |
| <div class="paragraph"> |
| <p>The synthesis algorithm computes various predicates, such as the conditions |
| under which the controllable events may take place in the controlled system, |
| and the initialization predicate of the controlled system. These predicates |
| are included in the supervisor that results from synthesis.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, if the controlled system imposes the exact same restrictions as the |
| uncontrolled system, there is no need to list the full conditions in the |
| supervisor, as the plants already define that behavior. The supervisor imposes |
| no additional restrictions with respect to the plants, and it suffices to use |
| <code>true</code> as condition for the supervisor to make that explicit.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are several predicates in the synthesis result that can be simplified |
| under the assumption of conditions that are already present in the input |
| specification. In some cases this leads to smaller/simpler supervisor |
| representations. In other cases it gives insight, indicating that the |
| supervisor does not impose any additional restrictions. The following |
| simplifications are available:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 15%;"> |
| <col style="width: 5%;"> |
| <col style="width: 30%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Option value</th> |
| <th class="tableblock halign-left valign-top">Default</th> |
| <th class="tableblock halign-left valign-top">Predicate</th> |
| <th class="tableblock halign-left valign-top">May be simplified assuming</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards-plants</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Supervisor guards of controllable events</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Plant guards, for the matching events</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards-req-auts</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Supervisor guards of controllable events</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">State/event exclusion requirement invariants derived from the |
| requirement automata, for the matching events</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards-se-excl-req-invs</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Supervisor guards of controllable events</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">State/event exclusion requirement invariants from the input |
| specification, for the matching events</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards-state-req-invs</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Supervisor guards of controllable events</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">State requirement invariants from the input specification (includes the |
| range requirement invariants added by the synthesis algorithm)</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>guards-ctrl-beh</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Supervisor guards of controllable events</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Controlled behavior as computed by synthesis</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>initial-unctrl</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Initialization predicate of the controlled system</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Initialization predicate of the uncontrolled system</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Which simplifications should be performed, can be specified using the |
| <em>BDD predicate simplify</em> option (see <a href="#tools-datasynth-options">options</a> |
| section above).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The table above lists in the first column, the option values to use for each of |
| the simplifications, on the command line. The names given in the first column |
| should be combined using commas, and used as option value. The simplifications |
| that are specified using the option replace the default simplifications (see |
| the second column of the table). However, it is also possible to specify |
| additions and removals relative to the default simplifications, by prefixing |
| simplifications (from the first column) with a <code>+</code> or <code>-</code> respectively. |
| Replacements (no prefix) may not be combined with additions/removals (<code>+</code> or |
| <code>-</code> prefix). Specifying a simplification twice leads to a warning being |
| printed to the console. Adding a simplification that is already present or |
| removing a simplification that is not present, also leads to a warning being |
| printed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the simplifications can be enabled or disabled |
| using a checkbox.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second column indicates for each simplification whether it is enabled by |
| default. By default, all simplifications are enabled. The third column |
| indicates the predicate in the synthesis result that can be simplified. The |
| fourth column indicates under the assumption of which predicate the |
| simplification is applied.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The simplification algorithm is not perfect, and may not simplify the |
| predicates as much as could potentially be possible.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When simplifying with respect to state requirement invariants, the supervisor |
| no longer enforces those requirements, as they are assumed to already hold. As |
| such, the simplification prevents such invariants from being removed from the |
| resulting CIF specification. This applies to some of the other simplifications |
| as well. For instance, the simplification over state/event exclusion |
| requirement invariants leads to them being part of the output as well. This may |
| affect whether other tools can handle the resulting supervisor model as input, |
| depending on what kind of features they support. In particular, for code |
| generation, simplification of the guards with respect to the state requirement |
| invariants and state/event exclusion requirement invariants may need to be |
| disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-dbg-output">Debug output</h5> |
| <div class="paragraph"> |
| <p>By default, the synthesis algorithm shows no progress information, and does not |
| explain how the resulting supervisor is obtained. By enabling debug output, |
| detailed information is printed to the console. Debug output can be enabled |
| by setting the |
| <b class="menuref">Output mode</b> |
| option (<b class="menuref">General</b> |
| category) to |
| <b class="menuref">Debug</b>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The debug output also contains information about the number of states in the |
| resulting controlled system (the uncontrolled system restricted by the |
| synthesized supervisor). If the resulting supervisor (and thus the controlled |
| system) is empty, or if |
| <a href="#tools-datasynth-forward-reach">forward reachability</a> is enabled, the |
| number of states that is printed is an exact number (e.g. <code>exactly 0 states</code>, |
| <code>exactly 1 state</code>, <code>exactly 1,234 states</code>). In other situations, the |
| controlled behavior predicate that is used to determine the number potentially |
| gives an over-approximation, and an upper bound on the number of states is |
| printed (e.g. <code>at most 1,234 states</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Enabling debug output may significantly slow down the synthesis algorithm, |
| especially for larger models. The performance degradation stems mostly from the |
| printing of predicates. Predicates are internally represented using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). To print them, |
| they are converted to CNF or DNF predicates, similar to one of the approaches |
| to <a href="#tools-datasynth-supervisor-bdd">convert</a> BDDs to CIF predicates for |
| synthesis output.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To limit the performance degradation, options are available to limit the |
| conversion of BDDs to CNF/DNF predicates. The <em>BDD debug max nodes</em> controls |
| the maximum number of BDD nodes for which to convert a BDD to a readable |
| CNF/DNF representation for the debug output. The default is <code>10</code> nodes. The |
| maximum must be in the range [1 .. 2<sup>31</sup> - 1]. |
| The option can be set to |
| have an infinite maximum (no maximum), using option value <code>inf</code>. The <em>BDD |
| debug max paths</em> option controls the maximum number of BDD true paths for which |
| to convert a BDD to a readable CNF/DNF representation for the debug output. The |
| default is <code>10</code> paths. The maximum must be in the range [1 .. 1.7e308]. The |
| option can be set to have an infinite maximum (no maximum), using option value |
| <code>inf</code>. If a BDD has more than the specified maximum number of nodes, or more |
| than the specified number of true paths, it is not converted to a CNF/DNF |
| predicate. Instead, it is converted to a textual representation that indicates |
| the number of nodes and true paths, e.g. <code><bdd 1,234n 5,678p></code> for a BDD with |
| 1,234 nodes and 5,678 true paths.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By limiting the conversion of BDDs to CNF/DNF predicates, debug output can |
| still be used for large models to see progress information, while not degrading |
| the performance too much.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-stats">Statistics</h5> |
| <div class="paragraph"> |
| <p>The data-based synthesis tool supports printing various kinds of statistics to |
| the console. By default, no statistics are printed. Statistics can be enabled |
| using the the <em>Statistics</em> option (see <a href="#tools-datasynth-options">options</a> |
| section above). The following statistics are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Timing</em> [<code>timing</code>]</p> |
| <div class="paragraph"> |
| <p>Print statistics for timing of various parts of the tool. Is printed to the |
| console, after execution, just termination of the tool. Timing is only |
| printed for parts of the tool that were actually executed. Timing is printed |
| as a tree. The root of the tree represents the total time of the synthesis |
| tool. For some parts of the tool, timing is also measured for sub-parts. |
| Timing is printed in milliseconds, to make it easier to compare timing for |
| various parts.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When measuring performance, always perform multiple measurements, and take |
| the average. Also, use a warm-up phase, to avoid skewed results.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>BDD garbage collection</em> [<code>bdd-gc</code>]</p> |
| <div class="paragraph"> |
| <p>The BDD library that is used maintains an internal node table. Whenever new |
| nodes no longer fit in the node table, a garbage collection is started by |
| the BDD library, to clean out all nodes that are no longer needed. BDD |
| garbage collection statistics are printed before and after garbage |
| collection. The printed information includes the size of the node table, the |
| number of free nodes, timing information, etc. See also the |
| BDD library initial node table size option (see |
| <a href="#tools-datasynth-options">options</a>` section above).</p> |
| </div> |
| </li> |
| <li> |
| <p><em>BDD node table resize</em> [<code>bdd-resize</code>]</p> |
| <div class="paragraph"> |
| <p>The BDD library that is used maintains an internal node table. Whenever new |
| nodes no longer fit in the node table, a garbage collection is started by |
| the BDD library, to clean out all nodes that are no longer needed. If only |
| very limited space could be reclaimed by garbage collection, the size of the |
| node table is increased. BDD node table resize statistics are printed when |
| the node table is resized. The printed information includes the old and the |
| new sizes of the node table. See also the BDD library initial node table |
| size option (see <a href="#tools-datasynth-options">options</a>` section above).</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the different kinds of statistics can be enabled |
| and disabled individually, using a checkbox.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>--stats</code> option, the names of the different |
| kinds of statistics, as indicated above between square brackets, should be |
| used, separated by commas. For instance, use <code>--stats=bdd-gc,bdd-resize</code> to |
| enable both BDD garbage collection statistics and BDD node table resize |
| statistics, but keep all other statistics disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying a statistics kind twice leads to a warning being printed to the |
| console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-early-problem-detection">Early problem detection</h5> |
| <div class="paragraph"> |
| <p>The synthesis algorithm checks the uncontrolled system for common issues, for |
| early detection of problems that will lead to an empty supervisor. If such a |
| problem is detected, a warning is printed to the console. Among others, checks |
| are included for no initial states/variables, no marked states, and no states |
| due to the invariants.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-var-order">BDD variable order</h5> |
| <div class="paragraph"> |
| <p>Internally, predicates are represented using |
| <a href="http://en.wikipedia.org/wiki/Binary_decision_diagram">Binary Decision Diagrams</a> |
| (BDDs). CIF |
| variables and automata are represented using one or more boolean variables |
| (also called BDD variables or bits). For instance, a boolean CIF variable is |
| represented using a single boolean/BDD variable, and a CIF variable of type |
| <code>int[0..8]</code> is represented using four boolean/BDD variables (9 possible |
| values, log<sub>2</sub>(9) ≈ 3.17). For each automaton with two or |
| more locations, a location pointer variable is created, that represents the |
| current or active location of that automaton. For instance, an automaton with |
| three locations is represented using two boolean/BDD variables. Two boolean/BDD |
| variables can represent 2<sup>2</sup> = 4 values, so one value is not |
| used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF variables and location pointer variables for the automata |
| (together called synthesis variables) can be ordered. This ordering can |
| significantly influence the performance of synthesis. Synthesis variables that |
| have a higher influence on the result of predicates (simply put, occur more |
| frequently in predicates) should generally be put earlier in the ordering. |
| Furthermore, in general, strongly related synthesis variables (e.g. by |
| comparison, integer computation, or assignment) should be kept closely together |
| in the order. For two synthesis variables <code>x</code> and <code>y</code>, examples of |
| predicates that introduce relations are <code>x = y</code> (by comparison) and |
| <code>5 < x + y</code> (by integer computation), and examples of assignments that |
| introduce relations are <code>x := y</code> and <code>x := y + 1</code> (both by assignment).</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the initial variable ordering, it is possible to order the BDD variables |
| per synthesis variable, or to interleave the BDD/boolean variables of some |
| synthesis variables. This can significantly influences the performance of |
| synthesis. Generally, strongly related synthesis variables should be |
| interleaved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For more information on ordering and its influence on performance, see |
| Chapter 3 of <a href="#minato">[minato]</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For each CIF variable and location pointer, two synthesis variables are |
| created, one storing the old/current value (before a transition), and one |
| storing the new value (after a transition). For a single CIF variable or |
| location pointer, the old and new synthesis variables are always kept together, |
| and interleaved. The old synthesis variable is also always before the new |
| synthesis variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The initial order of the boolean/BDD variables is determined by the |
| <em>BDD variable order</em> option (see <a href="#tools-datasynth-options">options</a> |
| section above). Several default orders exist, and it is also possible to |
| define a custom order. By default, the sorted order is used. The following |
| default orders exist:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>model ordering without interleaving</em> (option value <code>model</code>)</p> |
| <div class="paragraph"> |
| <p>The initial order of the synthesis variables is as they occur in the model. |
| A location pointer, for an automaton with two or more locations, is put |
| before the variables declared in that automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No synthesis variables are interleaved, except for each old variable with |
| its corresponding new variable.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>reverse model ordering without interleaving</em> (option value <code>reverse-model</code>)</p> |
| <div class="paragraph"> |
| <p>The initial order of the synthesis variables is as they occur in the model, |
| but reversed. A location pointer, for an automaton with two or more |
| locations, is put after the variables declared in that automaton, in this |
| reverse order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No synthesis variables are interleaved, except for each old variable with |
| its corresponding new variable. The old variables are still before the new |
| variables; this is not reversed.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>sorted ordering without interleaving</em> (option value <code>sorted</code>)</p> |
| <div class="paragraph"> |
| <p>The initial order of the synthesis variables is based on the names of the |
| variables and automata. They are sorted alphabetically in ascending |
| order, based on their absolute names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No synthesis variables are interleaved, except for each old variable with |
| its corresponding new variable.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>reverse sorted ordering without interleaving</em> (option value <code>reverse-sorted</code>)</p> |
| <div class="paragraph"> |
| <p>The initial order of the synthesis variables is based on the names of the |
| variables and automata. They are sorted alphabetically in descending |
| order, based on their absolute names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No synthesis variables are interleaved, except for each old variable with |
| its corresponding new variable. The old variables are still before the new |
| variables; this is not reversed.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>random ordering without interleaving</em> (option value <code>random</code> or <code>random:SEED</code>)</p> |
| <div class="paragraph"> |
| <p>The variables and automata are initially ordered randomly. If no |
| seed is specified, a random seed is used, resulting in a random random order. |
| If a seed is specified, a fixed random order is used. That is, using the same |
| seed again, results in the same random order. The <code>SEED</code> must be an integer |
| number in the range [0 .. 2<sup>64</sup> - 1]. For instance, use |
| <code>random:123</code> as option value to get a random order that can be repeated on |
| a subsequent synthesis for the same model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No synthesis variables are interleaved, except for each old variable with |
| its corresponding new variable.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Furthermore, a custom initial order can be defined. Custom orders consist of |
| absolute names of variables and automata. That is, for an automaton |
| <code>a</code>, with a discrete variable <code>x</code>, the absolute name of the variable is |
| <code>a.x</code>. The <code>*</code> character can be used as wildcard in those names, and |
| indicates zero or more characters. In case of multiple matches, the matches are |
| sorted increasingly on their absolute names, and interleaved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Multiple names can be separated with <code>;</code> characters. The synthesis variables |
| matching the name pattern before the <code>;</code> are ordered before the synthesis |
| variables matching the name pattern after the <code>;</code>. The <code>;</code> separator does |
| not introduce interleaving. The <code>,</code> separator can be used instead of the |
| <code>;</code> separator to introduce order but also introduce interleaving.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Each name pattern in the order must match at least one variable or automaton. |
| A variable or automaton may not be included more than once in the |
| order. Every variable and automaton (with two or more locations) needs to be |
| included in the order. It is not possible to specify new variables, as they |
| are always directly after their corresponding old variables, and they are |
| always interleaved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider two automata: <code>a</code> and <code>b</code>, each with three |
| variables of type <code>int[0..3]</code>: <code>x1</code>, <code>x2</code>, and <code>x3</code>. The automata have |
| three locations each, so location pointers are created for them. We thus have |
| six discrete variables: <code>a.x1</code>, <code>a.x2</code>, <code>a.x3</code>, <code>b.x1</code>, <code>b.x2</code>, and |
| <code>b.x3</code>, and two location pointer variables: <code>a</code> and <code>b</code>. Consider the |
| following custom order: <code>b*;a.x3,a.x1;a.x2,a</code>. Pattern <code>b*</code> matches |
| location pointer variable <code>b</code> as well as the three discrete variables of |
| automaton <code>b</code> (<code>b.x1</code>, <code>b.x2</code>, and <code>b.x3</code>). They are ordered in |
| increasing alphabetic order, and are interleaved. Variables <code>a.x3</code> and |
| <code>a.x1</code> are also interleaved, with <code>a.x3</code> before <code>a.x1</code>. Finally, variable |
| <code>a.x2</code> is ordered before the location pointer for automaton <code>a</code>, and they |
| are interleaved as well. This results in the following initial boolean/BDD |
| variable ordering, with bits whose name ends with <code>+</code> representing bits of |
| new variables rather than current/old variables, and <code>x#0</code> representing bit |
| zero of variable <code>x</code>:</p> |
| </div> |
| <div class="paragraph"> |
| <p><code>b#0</code><br> |
| <code>b+#0</code><br> |
| <code>b.x1#0</code><br> |
| <code>b.x1+#0</code><br> |
| <code>b.x2#0</code><br> |
| <code>b.x2+#0</code><br> |
| <code>b.x3#0</code><br> |
| <code>b.x3+#0</code><br> |
| <code>b#1</code><br> |
| <code>b+#1</code><br> |
| <code>b.x1#1</code><br> |
| <code>b.x1+#1</code><br> |
| <code>b.x2#1</code><br> |
| <code>b.x2+#1</code><br> |
| <code>b.x3#1</code><br> |
| <code>b.x3+#1</code></p> |
| </div> |
| <div class="paragraph"> |
| <p><code>a.x3#0</code><br> |
| <code>a.x3+#0</code><br> |
| <code>a.x1#0</code><br> |
| <code>a.x1+#0</code><br> |
| <code>a.x3#1</code><br> |
| <code>a.x3+#1</code><br> |
| <code>a.x1#1</code><br> |
| <code>a.x1+#1</code></p> |
| </div> |
| <div class="paragraph"> |
| <p><code>a.x2#0</code><br> |
| <code>a.x2+#0</code><br> |
| <code>a#0</code><br> |
| <code>a+#0</code><br> |
| <code>a.x2#1</code><br> |
| <code>a.x2+#1</code><br> |
| <code>a#1</code><br> |
| <code>a+#1</code></p> |
| </div> |
| <div class="paragraph"> |
| <p>The default orders are often not optimal performance-wise. Manually |
| specifying a custom order often requires specialist knowledge and can take |
| quite some time. Luckily, there are algorithms that can automatically compute |
| a decent variable order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The algorithms all take an initial variable ordering, and try to improve it |
| using a fast heuristic. A better initial variable ordering may result in a |
| better final variable ordering (a better local optimum), and may speed up the |
| automatic variable ordering algorithm (reaching an optimum faster).</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the initial variable ordering, the CIF variables and location pointers |
| may be arbitrarily interleaved. If an automatic variable ordering algorithm |
| changes the initial order, no synthesis variables are interleaved, except for |
| each old variable with its corresponding new variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The automatic variable ordering algorithms are not applied if the CIF model has |
| less than two synthesis variables. They are also not applied if the model has |
| no guards, updates, or other predicates to use as input for the algorithms, |
| i.e. there are no <em>hyperedges</em> to which to apply the algorithms.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following algorithms are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>FORCE</em></p> |
| <div class="paragraph"> |
| <p>The <a href="#force">[force]</a> algorithm is enabled by default, but can be disabled using the |
| <em>BDD FORCE variable ordering algorithm</em> option (see |
| <a href="#tools-datasynth-options">options</a> section above).</p> |
| </div> |
| <div class="paragraph"> |
| <p>At most 10 * ceil(log<sub>e</sub>(n)) iterations of the FORCE |
| algorithm are performed, with <code>n</code> the number of current/old BDD/boolean |
| variables.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Sliding window</em></p> |
| <div class="paragraph"> |
| <p>The sliding window algorithm is enabled by default, but can be disabled using |
| the <em>BDD sliding window variable ordering algorithm</em> option (see |
| <a href="#tools-datasynth-options">options</a> section above).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default maximum length of the window that is used is 4. The actual window |
| may be smaller, if less than 4 variables and/or location pointers are present |
| in the model. The maximum length of the window can be configured using the |
| <em>BDD sliding window size</em> option (see |
| <a href="#tools-datasynth-options">options</a> section above). The option to set |
| the maximum length only has effect if the sliding window variable ordering |
| algorithm is enabled. The size must be an integer number in the range |
| [1 .. 12].</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If enabled, the algorithms are applied in the order they are listed above.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-datasynth-op-caches">BDD operation caches</h5> |
| <div class="paragraph"> |
| <p>One of the main properties of BDDs is that they employ full sharing. That is, |
| if a part of a binary tree needs to be represented more than once, it is stored |
| only once, and reused. This leads to BDDs being represented using directed |
| acyclic graphs, rather than binary trees.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The BDD library uses an operation cache to speed up synthesis. Whenever a |
| certain operation is performed on one or more nodes of a BDD graph, the result |
| is cached. If that same operation is performed again on the same nodes, the |
| cached result is reused, if available. This way, repeated calculations can be |
| prevented for shared sub-graphs.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The operation cache is essential for the performance of the synthesis |
| algorithm. With infinite caches, the operations are generally linear in the |
| number of nodes used to represent the BDDs on which they are applied. Without |
| caching, the computation time grows exponentially.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Obviously, in practice we can’t have infinite caches, as a computer only has a |
| finite amount of memory available. We thus need to work with finite caches. |
| Whenever a new cached operation result doesn’t fit in the cache, an older |
| result is overwritten, and will need to be recomputed if it is needed again.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Increasing the cache size can significantly increase performance for large |
| systems, as a cache that is too small is ineffective, and results in many |
| operations needing to be repeated, that could have otherwise been obtained from |
| the cache. However, a larger than needed cache may also significantly decrease |
| performance, as a cache that is too large may no longer fit within CPU caches, |
| leading to more expensive accesses to the main memory rather than e.g. L1/L2/L3 |
| caches.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The operation cache size can be configured in two ways: as a fixed size that |
| remains the same during the entire synthesis, or a variable cache size that |
| grows in size as the node table grows in size. See the |
| <a href="#tools-datasynth-options">options</a> section above for details.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-performance">Performance</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-datasynth-options">options</a> have an effect on the |
| performance of data-based synthesis:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 5.2631%;"> |
| <col style="width: 15.7894%;"> |
| <col style="width: 15.7894%;"> |
| <col style="width: 21.0526%;"> |
| <col style="width: 42.1055%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Kind</th> |
| <th class="tableblock halign-left valign-top">Option</th> |
| <th class="tableblock halign-left valign-top">Section</th> |
| <th class="tableblock halign-left valign-top">Effect</th> |
| <th class="tableblock halign-left valign-top">Choose</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Output</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD output mode</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-supervisor-bdd">BDD representation in CIF</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Representation of BDDs in the output model</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Use <code>nodes</code> output variant for best performance</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Output</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD predicate simplify</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-simplification">Simplification</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Potentially smaller BDDs in the output</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enable for smaller output, although simplification itself also takes |
| time</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Order</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD variable order</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-var-order">BDD variable order</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Better order for smaller BDD representations</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Choose the best order, depends on the model, (reversed) model/sorted |
| usually good choices, custom order allows for best performance</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Order</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD FORCE variable ordering algorithm</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-var-order">BDD variable order</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Better order for smaller BDD representations</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enable for automatic ordering</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Order</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD sliding window variable ordering algorithm</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-var-order">BDD variable order</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Better order for smaller BDD representations</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enable for automatic ordering</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Order</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD sliding window size</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-var-order">BDD variable order</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Better order for smaller BDD representations</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Larger windows might allow for more optimization, but take more time</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Library</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD library initial node table size</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-stats">Statistics</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">More storage for less resizes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Increase size for less resizes, at the cost of less memory locality</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Library</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD library operation cache size/ratio</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-op-caches">BDD operation caches</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Increase cache for less computations</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enable, larger costs more memory, larger leads to less memory locality, |
| size/ratio depends on model</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Algorithm</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Forward reachability</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-forward-reach">Forward reachability</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Explore only reachable state space</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enable to reduce state space, although calculation itself may also be |
| expensive, depends on model</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Debug</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Output mode</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-dbg-output">Debug output</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Debug output on console</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Disable for better performance</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Debug</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">BDD debug max nodes/paths</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-dbg-output">Debug output</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Size of predicates in debug output</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The smaller, the less blowup, the better the performance</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Debug</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Statistics</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-datasynth-stats">Statistics</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Statistics output on console</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Disable for better performance</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>The first column categorizes the different options a bit, for different kind of |
| options. The second column lists the different options. The third column |
| indicates in which section on this page of the documentation you can find more |
| information about that option. The fourth column indicates the effect of the |
| option. The fifth column indicates what to choose for the option, for best |
| performance, although a trade-off may be involved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Obviously, the actual model that is used has a large impact as well. More |
| variables often leads to longer synthesis times. However, the predicates that |
| are used may also significantly impact performance.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Try to use state/event exclusion requirement invariants instead of requirement |
| automata with a single location and self loops. Also, try to avoid an |
| event-based modeling style, and use a data-based modeling style instead, if |
| possible.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-input-variables">Input variables</h5> |
| <div class="paragraph"> |
| <p>Data-based synthesis supports input variables. The model itself doesn’t specify |
| which value an input variable has at any given moment. Input variables can thus |
| have any value (as long as it fits within the data type of the variable), and |
| the value can change at any time. Input variables are ideal to model sensors.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To support this for data-based synthesis, the input variable is treated as a |
| discrete variable with an arbitrary initial value. To allow the input variable |
| to arbitrarily change, an uncontrollable event is added (with the same absolute |
| name as the input variable). Also, a single edge is added for that event. The |
| edge is always enabled (guard <code>true</code>, since the input variable can always |
| change value), and the update indicates that it can get any value that it |
| doesn’t currently have (<code>x+ != x</code> for <code>x</code> an input variable, with <code>x</code> |
| the value of the variable before the update, and <code>x+</code> the value of the |
| variable after the update). Obviously, the value of the input variable is kept |
| within the range of values that is allowed by its data type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using synthesis with requirements that restrict the allowed values of an input |
| variable will result in an empty supervisor, as a supervisor can’t prevent the |
| environment from changing the value of the input variable (it would have to |
| restrict the uncontrollable event that is internally added to model value |
| changes of the input variable). A supervisor can however impose additional |
| restrictions on the <a href="#tools-datasynth-init">initial</a> value of an input |
| variable. The supervisor can then only guarantee safe, non-blocking behavior |
| if the system is initialized in accordance with the additional initialization |
| restrictions.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-references">References</h5> |
| <div class="ulist bibliography"> |
| <ul class="bibliography"> |
| <li> |
| <p><a id="minato"></a>[minato] Shin-ichi Minato. Binary Decision Diagrams and Applications for |
| VLSI CAD: The Springer International Series in Engineering and Computer Science, |
| Volume 342, 1996, Springer US, ISBN 978-1-4613-1303-8 (E-book), |
| ISBN 978-0-7923-9652-9 (hardcover), ISBN 978-1-4612-8558-8 (softcover)</p> |
| </li> |
| <li> |
| <p><a id="force"></a>[force] Fadi A. Aloul, Igor L. Markov, Karem A. Sakallah. |
| FORCE: A Fast and Easy-To-Implement Variable-Ordering Heuristic: |
| GLSVLSI '03 Proceedings of the 13th ACM Great Lakes symposium on VLSI |
| pages 116-119, 2003, ACM New York, NY, USA, ISBN 1-58113-677-3</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-eventbased-chapter-index">Event-based synthesis toolset</h4> |
| <div class="paragraph"> |
| <p> |
| |
| Synthesis, 'supervisor synthesis', or 'supervisory controller synthesis', is a |
| generative technique, where one derives a (supervisor) automaton from a |
| collection of plants and requirements. The resulting supervisor is maximally |
| permissive under the conditions of being free of deadlocks, and always having |
| the option of reaching a marked state.</p> |
| </div> |
| <div class="paragraph"> |
| <p>While there is only one true synthesis tool (the tool that actually derives a |
| supervisor automaton from a collection of plant and requirement automata), |
| other tools exist to support the process. These tools together form the |
| <em>event-based synthesis toolset</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>These tools use and modify the sequences of events that can be performed. This |
| in contrast to state-based tools, which operate primarily on the |
| <a href="#tools-cifsim-traces-state">state</a> of the system. Event sequences |
| directly hook into language theory, which places these tools firmly in the |
| language theory mathematical framework.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-supported-specifications">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The application supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Channels (events with data types), if used (present on an edge of at least |
| one automaton), are not supported.</p> |
| </li> |
| <li> |
| <p>Any use of the <code>tau</code> event is not supported. Note that both explicit use |
| (keyword <code>tau</code>) and implicit use (no events on an edge) are unsupported.</p> |
| </li> |
| <li> |
| <p>Automata with multiple initial locations are not supported.</p> |
| </li> |
| <li> |
| <p>Edges with updates are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent locations and edges are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in components are not supported.</p> |
| </li> |
| <li> |
| <p>Invariants in components are not supported.</p> |
| </li> |
| <li> |
| <p>Marker predicates in components are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in locations that are not trivially true or false |
| are not supported.</p> |
| </li> |
| <li> |
| <p>State invariants in locations that are not trivially true are not supported.</p> |
| </li> |
| <li> |
| <p>Marker predicates in locations that are not trivially true or false are not |
| supported.</p> |
| </li> |
| <li> |
| <p>State/event exclusion invariants are not supported.</p> |
| </li> |
| <li> |
| <p>Guards of edges that are not trivially true or false are not supported.</p> |
| </li> |
| <li> |
| <p>Multiple initialization predicates in a single location are not supported.</p> |
| </li> |
| <li> |
| <p>Multiple state invariant predicates in a single location are not supported.</p> |
| </li> |
| <li> |
| <p>Multiple marker predicates in a single location are not supported.</p> |
| </li> |
| <li> |
| <p>Multiple guards on a single edge are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>To allow state/event exclusion invariants to be used in the input, manually |
| eliminate them first using the <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> |
| CIF to CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For meaningful results, it is recommended to have an initial location and at |
| least one marked location, in each automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-3">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-kinds">Automaton kinds</h5> |
| <div class="paragraph"> |
| <p>The event-based toolset recognizes the CIF automaton kinds <code>plant</code>, |
| <code>requirement</code>, and <code>supervisor</code>, and interprets them using the |
| corresponding concepts of the mathematical framework of supervisor synthesis. |
| Kindless/regular automata (without a supervisory kind) are treated as unknown.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-location-names-in-reports-and-errors">Location names in reports and errors</h5> |
| <div class="paragraph"> |
| <p>Several tools output reports or give errors with locations that are |
| interesting in some way.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Tools that take a single automaton as input report locations by their name in |
| the input specification, for example <code>location "button.off"</code> denotes the |
| <code>off</code> location in the <code>button</code> automaton. The location of automata that |
| have a single unnamed location use <code>*</code> as location name, for example |
| <code>location "req.*"</code> denotes the single unnamed location in the <code>req</code> |
| automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Tools that take a number of automata together, like supervisor synthesis |
| report interesting states as <code>state</code> followed by the names of the locations, |
| for example <code>state "button.on", "machine.idle"</code>. Such a state refers to a |
| location that represents the combined locations of the automata, in the |
| example, the combined locations <code>button.off</code> and <code>machine.idle</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Tools that combine or merge locations, like projection, report such combined |
| locations as a partition, for example <code>partition "machine.down", |
| "machine.off"</code> represents a location that is a combination of the <code>down</code> |
| and the <code>off</code> locations in the <code>machine</code> automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-available-tools">Available tools</h5> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-eventbased-chapter-product">Event-based synchronous product</a></p> |
| <div class="paragraph"> |
| <p>Computes the product of a number of deterministic or non-deterministic |
| automata, where common events are synchronized. Essentially computes the |
| <a href="#tools-cifsim-traces-state-space">state space</a>.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-supervisorsynthesis">Event-based supervisor synthesis</a></p> |
| <div class="paragraph"> |
| <p>Derivation of a maximal permissive supervisor from a collection of |
| deterministic plant and requirement automata.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-synthesis-analysis">Event-based synthesis analysis</a></p> |
| <div class="paragraph"> |
| <p>Analysis of the removed parts of a synthesized supervisor.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-nonconflicting-check">Event-based nonconflicting check</a></p> |
| <div class="paragraph"> |
| <p>Verifies whether automata are conflicting, that is together could lead to |
| non-coreachable states.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-controllability-check">Event-based controllability check</a></p> |
| <div class="paragraph"> |
| <p>Verifies whether the supervisor does not disable uncontrollable events |
| of the plant.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-language-equivalence-check">Event-based language equivalence check</a></p> |
| <div class="paragraph"> |
| <p>Verifies whether two automata produce the same events at each point.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-nfa-to-dfa">Event-based NFA to DFA automaton conversion</a></p> |
| <div class="paragraph"> |
| <p>Converts a non-deterministic automaton to a deterministic automaton while |
| preserving the event behavior.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-dfa-minimization">Event-based DFA minimization</a></p> |
| <div class="paragraph"> |
| <p>Minimize the number of locations of an automaton while preserving the |
| event behavior.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-projection">Event-based automaton projection</a></p> |
| <div class="paragraph"> |
| <p>Computes a projection of an automaton, resulting in a deterministic and |
| language equivalent automaton over a subset of its alphabet.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-observer-check">Event-based observer check</a></p> |
| <div class="paragraph"> |
| <p>Verifies whether an automaton can act as an observer of occurrences of |
| observable events.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-automaton-abstraction">Event-based automaton abstraction</a></p> |
| <div class="paragraph"> |
| <p>Abstracts an automaton to a set of observable events.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-trim-check">Event-based trim check</a></p> |
| <div class="paragraph"> |
| <p>Verifies whether the automata are trim, that is, in each automaton, the |
| locations must be both reachable and co-reachable.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-eventbased-chapter-trim">Event-based trim</a></p> |
| <div class="paragraph"> |
| <p>Removes all locations that are not reachable or coreachable.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-product">Event-based synchronous product</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The event-based synchronous product takes one or more plant or requirement |
| automata, and computes the synchronous product. Synchronous product means |
| events on edges can only be taken if all automata with that event in their |
| alphabet can take an edge with the same event at that time. This tool |
| essentially computes the <a href="#tools-cifsim-traces-state-space">state space</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing all automata to combine, and |
| produces a new <code>.cif</code> file with the product automaton. If the |
| <a href="#tools-eventbased-kinds">kinds</a> of the source automata are all the same, |
| the resulting product automaton is of that kinds as well. Otherwise, the |
| product automaton has unknown kind.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-synchronous-product-tool">Starting the synchronous product tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply synchronous product…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply synchronous product…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifprod</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifprod</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_product.cif</code> file extension is added. The <code>product</code> part of the default |
| extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the product automaton. If not specified, |
| defaults to <code>product</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-supervisorsynthesis">Event-based supervisor synthesis</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The supervisor synthesis procedure takes one or more deterministic plant |
| automata, one or more deterministic requirement automata, and combines |
| them to a maximal permissive supervisor.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The tool takes a <code>.cif</code> file containing <code>plant</code> and <code>requirement</code> |
| automata. Besides the general event-based restrictions listed at |
| <a href="#tools-eventbased-supported-specifications">Supported specifications</a>, the current implementation |
| does not support:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Having no <code>plant</code> automata at all.</p> |
| </li> |
| <li> |
| <p>Having no <code>requirement</code> automata at all.</p> |
| </li> |
| <li> |
| <p>Having any other kind of automaton in the file. See |
| <a href="#tools-eventbased-kinds">Automaton kinds</a> for a list of all automaton kinds.</p> |
| </li> |
| <li> |
| <p>Non-determinism in the input automata. The tool reports the violating |
| automaton, location, and event, for ease of reference.</p> |
| </li> |
| <li> |
| <p>Events in the alphabet of the requirements that are not in the alphabet of |
| the plants.</p> |
| </li> |
| <li> |
| <p>Events that are not controllable or uncontrollable, if used (present in the |
| alphabet or on an edge of at least one automaton).</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In addition, it warns about common mistakes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Automata without a marked location.</p> |
| </li> |
| <li> |
| <p>Non-<a href="#tools-eventbased-chapter-trim-check">trim</a> automata.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Finally, it can also perform checks about correct constructs that may not be |
| the intention of its author. Each of these checks has to be enabled with an |
| option:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Automata with a marked deadlock location. In a system with infinite |
| behavior, you should probably never enter a deadlock location.</p> |
| </li> |
| <li> |
| <p>Automata with an empty alphabet. Such automata never participate in an |
| event, and can be removed.</p> |
| </li> |
| <li> |
| <p>Controllable events that are used in exactly one automaton. Not always |
| wrong, but creating a controllable event, and not using it for control may |
| be a mistake.</p> |
| </li> |
| <li> |
| <p>Groups of automata that share events only within the group (and not with any |
| automaton outside the group). Such a group is completely independent, and |
| can be synthesized separately.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The synthesis tool produces a new <code>.cif</code> file with the supervisor |
| automaton (of kind <code>supervisor</code>) if the resulting automaton has at |
| least an initial location. Otherwise, synthesis fails with a <code>Supervisor is |
| empty</code> error, and no <code>.cif</code> file is written.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-supervisor-synthesis-tool">Starting the supervisor synthesis tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply supervisor synthesis…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply supervisor synthesis…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsupsynth</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsupsynth</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-2">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_sup.cif</code> file extension is added. The <code>sup</code> part of the default |
| extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the supervisor automaton. If not |
| specified, defaults to <code>sup</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| <li> |
| <p><em>Enable Synthesis dump</em>: If enabled, the synthesis algorithm writes a |
| dump file containing the actions performed by the algorithm, for later |
| analysis. The name of the file is decided by the <em>Dump file</em> option.</p> |
| </li> |
| <li> |
| <p><em>Synthesis dump file</em>: The name of the dump file. Setting this option will enable |
| dumping of the synthesis algorithm actions. The options contains the |
| absolute or relative local file system path to the |
| synthesis dump file. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>.synth_dump</code> file extension is added.</p> |
| </li> |
| <li> |
| <p><em>Disjunct groups check</em>: If enabled, the tool will report about groups of |
| automata that share events in the group only.</p> |
| </li> |
| <li> |
| <p><em>Empty alphabet check</em>: If enabled, the tool will report about automata |
| without events in their alphabet.</p> |
| </li> |
| <li> |
| <p><em>Marked deadlock location check</em>: If enabled, the tool will report about |
| marked locations without outgoing edges.</p> |
| </li> |
| <li> |
| <p><em>Single use controllable check</em>: If enabled, the tool will report about |
| controllable events that are used in exactly one automaton.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-synthesis-analysis">Event-based synthesis analysis</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| While developing a controller with supervisory controller synthesis, the |
| result is not always what you expect. To assist, the synthesis analysis tool |
| has been developed. Its primary purpose is to explain why certain states or |
| edges have been removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To use the tool, enable creation of the <em>Synthesis Dump</em> file during |
| synthesis, using the <em>Enable Synthesis dump</em> option or the <em>Synthesis dump |
| file</em> option of the <a href="#tools-eventbased-chapter-supervisorsynthesis">Supervisor synthesis tool</a>.</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_enable_synthesis_dump.png" alt="analysis enable synthesis dump"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By double clicking the generated dump file, or by right-clicking the dump file |
| and selecting |
| <b class="menuref">Analyze Synthesis Result</b>, |
| the analysis tool is |
| started. It loads the file (which can take a some time if the file is big), |
| eventually giving the following display:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_startup.png" alt="analysis startup"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>At the left, all automata with their initial location are shown. You can |
| select a different supervisor state by changing these locations. At the top, |
| in the middle, there are three buttons. The bottom button labeled <em>Search |
| state</em> is used to search the information about a supervisor state selected at |
| the left. The <em>Jump to initial state</em> button resets the automata locations |
| to their initial state, useful when you want to start again. The middle button |
| is disabled now, but allows you to go back to the previous state.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At the right, a number of options are available in case the displayed |
| information is not sufficient. These are explained later.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Below the buttons and options is the report area, which just displays some |
| statistics. When you press <em>Search</em>, the tool analyzes the selected state at |
| the left. Depending on what happened with that state, different things may be |
| shown. In this example, you get:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_basic.png" alt="analysis basic"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The report area changes to display the information about the selected state. |
| It starts with the internal number of this state (<code>#0</code>), and its properties. |
| The <code>initial</code> means this state is the initial state, <code>marked</code> means this |
| state is marked. Then follows an explicit list of locations of every |
| automaton. It is the same list as the selected locations at the left, but more |
| compact. Then the analysis result is shown. This state exists in the |
| supervisor, and has no outgoing edges. In other words, this state is the only |
| state in the result. Below it, the edges removed by the requirements are |
| listed, together with the name of the requirement automaton that disabled it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Not displayed here is the list of edges removed due to plant automata. These |
| can be displayed by enabling the <em>Display disabled plant events</em> option at the |
| top-right.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a state does have outgoing edges, these are displayed as well:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_outgoing.png" alt="analysis outgoing"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>State <code>#7</code> has one outgoing edge, leading to state <code>#9</code> using event |
| <code>Sensor_In_Off</code>. The last line with the removed controllable events |
| displays a removed edge because destination state <code>#8</code> was removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If you want to know what states <code>#9</code> or <code>#8</code> are, you can enable the |
| <em>Display full state</em> at the top-right, and the tool will display the full |
| list of automaton locations with each state, just like the first line in the |
| report. You can also go to these states, by double-clicking at the blue area. |
| If you click at removed state <code>#8</code> you get a display like:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_removed.png" alt="analysis removed"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As expected, the analysis tools displays that the state was removed, |
| apparently because it was not co-reachable. Again you get the list of removed |
| edges from this state, as an aid to decide which requirement should be |
| checked, if this was not expected.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The final screenshot shows what is displayed if a state is removed because |
| another state is removed:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/eventbased/analysis_chain.png" alt="analysis chain"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is an example from a bigger system, where the supervisor is empty. The |
| analysis of the initial state reveals that it was removed due to a removal of |
| a chain of other states. State <code>#24</code> was removed due to a requirement |
| (reading from bottom to top), which caused the chain of states <code>#9</code>, <code>#2</code>, |
| and eventually <code>#0</code> to be removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Removed edges with controllable events are not displayed here, since these |
| have no influence to the disappearing of the states. If you want, you can |
| display them by toggling the <em>Always display disabled controllable events</em> |
| option at the top-right.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In this example, the number of states in the chain to the disabling |
| requirement was 4 states. This chain can be longer. Usually the middle part |
| is not that interesting and it is omitted from the display, but if you want to |
| see them, you can increase the number of displayed states at the top-right |
| (which is by default <code>5</code>). |
| Another way to see them is to double-click at a state in the chain, and the |
| analysis tool will display the chain starting from that state.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A situation that is not shown here, is that the analysis tool has no |
| information about a state. It happens when the synthesis encountered a bad |
| state on all paths to that state. In such a case, it displays that there is no |
| information about the queried state.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-synthesis-analysis-tool">Starting the synthesis analysis tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, double-click a <code>.synth_dump</code> file generated by the supervisor |
| synthesis dump.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click a <code>.synth_dump</code> file in the |
| 'Project Explorer' tab or 'Package Explorer' tab and choose |
| <b class="menuref">Analyze Synthesis Result</b>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsynthanalys</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsynthanalys</code> |
| command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-3">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input Synthesis dump file.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-nonconflicting-check">Event-based nonconflicting check</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The nonconflicting check verifies whether two or more automata are conflicting, |
| that is, whether they together could result in non-coreachable states.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One practical application is to check a supervisor, either synthesized or |
| manually created, against a plant. That is, when the supervisor is used to |
| control the plant, will it always stay in the safe coreachable area? If not, at |
| what point does it fail to do so?</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another practical application is to check several supervisors synthesized for |
| parts of a system. That is, when the supervisors are used together to control |
| a system, could that result in non-coreachable states? If so, which states are |
| conflicting?</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing two or more automata, that must be |
| both deterministic and trim. Besides those restrictions, the general |
| event-based restrictions listed at |
| <a href="#tools-eventbased-supported-specifications">Supported specifications</a> apply as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The nonconflicting check tool produces a text file, listing the traces that |
| lead to a conflicting state. If no such traces are found, the automata are |
| nonconflicting.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-nonconflicting-check-tool">Starting the nonconflicting check tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply nonconflicting check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply nonconflicting check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifncchk</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifncchk</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-4">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Report file</em>: The absolute or relative local file system path to the |
| output report file with conflicts. If not specified, defaults to the input |
| file path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_conflicts.txt</code> file extension is added.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-controllability-check">Event-based controllability check</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The controllability check verifies whether a supervisor automaton does not |
| disable edges with uncontrollable events of the (combined) plant automata. If |
| the check fails, the tool reports where it fails. If the check succeeds, it |
| reports the edges with controllable events that are disabled by the |
| supervisor.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The tool takes a <code>.cif</code> file containing a <code>supervisor</code> automaton, and one |
| or more <code>plant</code> automata. Besides the general event-based restrictions listed |
| at <a href="#tools-eventbased-supported-specifications">Supported specifications</a>, the current implementation |
| does not support:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Having more than one <code>supervisor</code> automaton.</p> |
| </li> |
| <li> |
| <p>Having no <code>plant</code> or <code>supervisor</code> automaton.</p> |
| </li> |
| <li> |
| <p>Having an automaton with a different kind than <code>plant</code> or <code>supervisor</code>.</p> |
| </li> |
| <li> |
| <p>Having a non-deterministic automaton.</p> |
| </li> |
| <li> |
| <p>Events that are not controllable or uncontrollable, if used (present in the |
| alphabet or on an edge of at least one automaton).</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The controllability check tool produces a report text file with its findings. |
| It states whether the controllability property holds (no edges with |
| uncontrollable events of the plant are disabled) or fails (one or more edges |
| with uncontrollable events in the plant are disabled by the supervisor).</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the controllability property holds, the tool lists the disabled controllable |
| events, which can be useful in the design process. If the property fails, the |
| tool lists the edges that are disabled by the supervisor.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-controllability-check-tool">Starting the controllability check tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply controllability check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply controllability check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifctrlchk</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifctrlchk</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-5">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Report file</em>: The absolute or relative local file system path to the |
| output report file with disabled events. If not specified, defaults to the |
| input file path, where the <code>.cif</code> file extension is removed (if present), |
| and a <code>_disableds.txt</code> file extension is added.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-language-equivalence-check">Event-based language equivalence check</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The language equivalence check verifies whether two automata produce the same |
| language, that is, at every point they are marked in the same way and can |
| produce the same events. Note that even automata with a different number of |
| locations or edges can be language equivalent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All reachable locations of the automata are checked. In particular, it also |
| checks locations that are outside the marked behavior (that is, reachable |
| locations that are not marked and are not on a path to a marked location). To |
| avoid false positives, you may want to ensure that both automata are |
| <a href="#tools-eventbased-chapter-trim">trim</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One practical application is to verify whether a manually created supervisor |
| is equivalent to an automatically generated one. If they are not, a counter |
| example is produced.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing exactly two automata, that must |
| be deterministic, have the same alphabet, and have an initial location. In |
| addition, the general event-based restrictions listed at |
| <a href="#tools-eventbased-supported-specifications">Supported specifications</a> apply as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The language equivalence check tool produces output stating |
| <code>Automata have the same language</code>, or it produces a counter example |
| where an event can be |
| performed in a location in one automaton, while from the equivalent |
| location in the other automaton the same event cannot be performed. |
| The equivalent location is derived by walking from the initial |
| location to the location of interest in both automata, using the same |
| sequence of events.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-language-equivalence-check-tool">Starting the language equivalence check tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply language equivalence check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply language equivalence check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciflngeqv</code> tool in a ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciflngeqv</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-6">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-nfa-to-dfa">Event-based NFA to DFA automaton conversion</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The event-based NFA to DFA automaton conversion takes an non-deterministic |
| automaton. The algorithm produces a deterministic automaton with the same |
| language.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing a single automaton. The output is |
| a <code>.cif</code> file containing a deterministic automaton that is language |
| equivalent with the input automaton. The resulting automaton has the same kind |
| as the input automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-nfa-to-dfa-automaton-conversion-tool">Starting the NFA to DFA automaton conversion tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply NFA to DFA automaton conversion…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply NFA to DFA automaton conversion…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifnfadfa</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifnfadfa</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-7">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_dfa.cif</code> file extension is added. The <code>dfa</code> part of the |
| default extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the projected automaton. If not |
| specified, defaults to <code>dfa</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-dfa-minimization">Event-based DFA minimization</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| Minimizing the number of locations of an automaton while preserving the |
| language gives a canonical representation of the language, making it easier to |
| compare automata. The DFA minimization tool computes such a minimal automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing one deterministic automaton with an |
| initial location. In addition, the general event-based restrictions listed at |
| <a href="#tools-eventbased-supported-specifications">Supported specifications</a> apply as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The DFA minimization tool produces an automaton with the same language, but |
| with the minimal number of locations. If the original automaton already had |
| the minimal number of locations, the result is the same as the input.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-dfa-minimization-tool">Starting the DFA minimization tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply DFA minimization…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply DFA minimization…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifdfamin</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifdfamin</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-8">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_minimal.cif</code> file extension is added. The <code>minimal</code> part of the default |
| extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the minimized automaton. If not specified, |
| defaults to <code>minimal</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-projection">Event-based automaton projection</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The event-based automaton projection takes an automaton and a subset of the |
| events of its alphabet that should be preserved. The other events of the |
| alphabet are considered to be internal steps and get replaced by <code>epsilon</code> |
| at the edges. The algorithm produces a deterministic automaton with the subset |
| as its alphabet that has the same language.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing a single automaton, and the names |
| of the events that should be preserved. The output is a <code>.cif</code> file |
| containing a deterministic automaton that is language equivalent with the |
| input automaton with respect to the set of preserved events. |
| The resulting automaton has the same kind as the input automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-automaton-projection-tool">Starting the automaton projection tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply automaton projection…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply automaton projection…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifproj</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifproj</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-9">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Preserved events</em>: Comma and/or whitespace separated absolute names of |
| events that should be preserved.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_projected.cif</code> file extension is added. The <code>projected</code> part of the |
| default extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the projected automaton. If not |
| specified, defaults to <code>projected</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-observer-check">Event-based observer check</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The event-based observer check takes an automaton, and a subset of the events |
| of its alphabet that are observable. The check verifies whether the automaton |
| after projection (see <a href="#tools-eventbased-chapter-projection">Event-based automaton projection</a>) can derive the |
| (abstracted) state of another component by synchronizing only on the |
| observable events.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing a single automaton, and the names |
| of the events that are observable. The output is a report file that indicates |
| whether the observer check property holds. If it fails, the events causing |
| failure are also listed.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-observer-check-tool">Starting the observer check tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply observer check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply observer check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifobschk</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifobschk</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-10">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Observable events</em>: Comma and/or whitespace separated absolute names of |
| events that are observable.</p> |
| </li> |
| <li> |
| <p><em>Report file</em>: The absolute or relative local file system path to the |
| output report file. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_observation.txt</code> file extension is added.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-automaton-abstraction">Event-based automaton abstraction</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The event-based automaton abstraction takes an automaton, and a subset of the events |
| of its alphabet that are observable. The abstraction produces a |
| non-deterministic abstracted automaton with the observable events as its |
| alphabet, that is weakly bisimilar to the original automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tool takes a <code>.cif</code> file containing a single automaton, and the names |
| of the events that are observable. The output is a <code>.cif</code> file with the |
| abstracted automaton. The resulting automaton has the same kind as the input |
| automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-automaton-abstraction-tool">Starting the automaton abstraction tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply automaton abstraction…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply automaton abstraction…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifabstr</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifabstr</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-11">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Observable events</em>: Comma and/or whitespace separated absolute names of |
| events that are observable.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF file. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_abstracted.cif</code> file extension is added. The <code>abstracted</code> part of the |
| default extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the abstracted automaton. If not |
| specified, defaults to <code>abstracted</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-trim-check">Event-based trim check</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This check verifies that the automata in the given file are trim, that is, in |
| each automaton, all the locations must be both reachable and coreachable. If |
| the check fails for one or more automata, the tool reports for each automaton, |
| whether all its locations are reachable and coreachable. It also lists the |
| locations where the property fails.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-trim-check-tool">Starting the trim check tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply trim check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply trim check…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciftrimchk</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciftrimchk</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-12">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Report file</em>: The absolute or relative local file system path to the |
| output report file with disabled events. If not specified, defaults to the |
| input file path, where the <code>.cif</code> file extension is removed (if present), |
| and a <code>_trimcheck.txt</code> file extension is added.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-eventbased-chapter-trim">Event-based trim</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The trim tool makes an automaton trim by removing all locations that are not |
| reachable or coreachable. |
| The input is a <code>.cif</code> file with a single automaton, and the tool produces a |
| new <code>.cif</code> file with the trim automaton. If the automaton in the input was |
| already trim, all locations are preserved.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-trim-tool">Starting the trim tool</h6> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply trim…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">Event-based synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply trim…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciftrim</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>ciftrim</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-13">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_trim.cif</code> file extension is added. The <code>trim</code> part of the default |
| extension depends on the <em>Result name</em> option.</p> |
| </li> |
| <li> |
| <p><em>Result name</em>: The name to use for the trim automaton. If not |
| specified, defaults to <code>trim</code>. Also affects the <em>Output file</em> option.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-cif2supremica">CIF to Supremica transformer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF to Supremica transformer can be used to transform CIF specifications |
| to Supremica modules (<code>*.wmod</code> files). |
| <a href="http://supremica.org/">Supremica</a> |
| is a tool for synthesis of discrete event supervisors.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-3">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to Supremica…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF synthesis tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to Supremica…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2supremica</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2supremica</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2supremica-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative local file system path to the |
| output Supremica module file. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>.wmod</code> file extension is added.</p> |
| </li> |
| <li> |
| <p><em>Supremica module name</em>: The name of the Supremica module. If not specified, |
| defaults to the name of the output file, after removal of the <code>.wmod</code> |
| extension (if present).</p> |
| </li> |
| <li> |
| <p><em>Eliminate enumerations</em>: Enable this option to eliminate enumerations before |
| generating transforming to Supremica. Disable this option to keep |
| enumerations in the generated Supremica module. By default this option is |
| disabled.</p> |
| <div class="paragraph"> |
| <p>Even though Supremica supports enumerations in its language, it doesn’t |
| support them in all its algorithms. Even if the original CIF transformation |
| being transformed does not use enumerations, enumerations may still be |
| generated internally during |
| <a href="#tools-cif2supremica-preprocessing">preprocessing</a>.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-3">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The CIF to Supremica transformer supports a subset of CIF specifications. The |
| following restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Kindless/regular automata (without a supervisory kind) are not supported. |
| Only <code>plant</code>, <code>requirement</code>, and <code>supervisor</code> automata are supported.</p> |
| </li> |
| <li> |
| <p>Events not declared as controllable or uncontrollable are not supported. |
| This includes the <code>tau</code> event, both explicitly used on edges, as well as |
| implicitly for edges without explicitly mentioned events.</p> |
| </li> |
| <li> |
| <p>Initialization predicates outside of locations are not supported.</p> |
| </li> |
| <li> |
| <p>Marker predicates outside of locations are only supported if they have the |
| form <code>discrete_variable = marked_value</code>.</p> |
| </li> |
| <li> |
| <p>Discrete variables with multiple marker predicates are not supported.</p> |
| </li> |
| <li> |
| <p>Locations with initialization or marker predicates that are not trivially |
| true or false are not supported.</p> |
| </li> |
| <li> |
| <p>Automata that do not have exactly one initial location are not supported.</p> |
| </li> |
| <li> |
| <p>Invariants in locations are not supported.</p> |
| </li> |
| <li> |
| <p>Invariants are only supported if they are requirement invariants.</p> |
| </li> |
| <li> |
| <p>Only state invariants are supported. State/event exclusion invariants are |
| not supported. To allow state/event exclusion invariants to be used in the |
| input, manually eliminate them first using the |
| <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> CIF to CIF transformation.</p> |
| </li> |
| <li> |
| <p>Discrete variables that have multiple potential initial values |
| (<code>in {...}</code> or <code>in any</code>) are not supported.</p> |
| </li> |
| <li> |
| <p>Continuous variables are not supported.</p> |
| </li> |
| <li> |
| <p>Input variables are currently unsupported.</p> |
| </li> |
| <li> |
| <p>Multi-assignments on edges (such as <code>do (x, y) := (1, 2)</code>) are not |
| supported. However, it is allowed to use multiple assignments on an edge |
| (such as <code>do x := 1, y := 2</code>).</p> |
| </li> |
| <li> |
| <p>Partial variable assignments (such as <code>do x[0] := 5</code>) are not supported.</p> |
| </li> |
| <li> |
| <p>Conditional updates on edges (such as <code>do if b: x := 5 end</code>) are not |
| supported.</p> |
| </li> |
| <li> |
| <p>Urgent locations and urgent edges are not supported.</p> |
| </li> |
| <li> |
| <p>User-defined functions are not supported.</p> |
| </li> |
| <li> |
| <p>Channels (events with data types) are not supported.</p> |
| </li> |
| <li> |
| <p>Only the following data types are supported: boolean types, ranged integer |
| types, and enumeration types.</p> |
| </li> |
| <li> |
| <p>Only the following expressions are supported: boolean literal values, integer |
| literal values, binary expressions (partially, see below), unary expressions |
| (partially, see below), and references to constants, discrete variables, |
| enumeration literals, and casts that don’t change the type.</p> |
| </li> |
| <li> |
| <p>Only the following binary operators are supported: logical equivalence |
| (<code><=></code>), logical implication (<code>=></code>), conjunction (<code>and</code>) on boolean |
| operands, disjunction (<code>or</code>) on boolean operands, addition (<code>+</code>) on |
| ranged integer operands, subtraction (<code>-</code>) on ranged integer operands, |
| multiplication (<code>*</code>) on ranged integer operands, integer division (<code>div</code>) |
| on ranged integer operands, integer modulus (<code>mod</code>) on ranged integer |
| operands, equality (<code>=</code>), inequality (<code>!=</code>), less than (<code><</code>) on ranged |
| integer operands, less than or equal to (<code><=</code>) on ranged integer operands, |
| greater than (<code>></code>) on ranged integer operands, and greater than or equal to |
| (<code>>=</code>) on ranged integer operands.</p> |
| </li> |
| <li> |
| <p>Only the following unary operators are supported: logical inverse (<code>not</code>), |
| negation (<code>-</code>) on a ranged integer operand, and plus (<code>+</code>) on a ranged |
| integer operand.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2supremica-preprocessing">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-pos-info">Remove position information</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-alg-vars">Eliminate algebraic variables</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-type-decls">Eliminate type declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-monitors">Eliminate monitors</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a> (if enabled via the corresponding |
| <a href="#tools-cif2supremica-options">option</a>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-others">Simplify others</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-transformation-result">Transformation result</h5> |
| <div class="paragraph"> |
| <p>The CIF automata kinds <code>plant</code>, <code>requirement</code>, and <code>supervisor</code> are |
| mapped to Supremica kinds <code>Plant</code>, <code>Specification</code>, and <code>Supervisor</code>, |
| respectively.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All generated Supremica automata are tagged as non-deterministic, as CIF |
| automata may be non-deterministic.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Nameless CIF locations are given the name <code>X</code> in Supremica automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Supremica does not support boolean values. Instead of <code>true</code>, value <code>1</code> is |
| used, and instead of <code>false</code>, value <code>0</code> is used. For boolean types |
| (<code>bool</code>), ranged integer types (<code>int[0..1]</code>) are used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The absolute names of all CIF objects (automata, variables, etc) are used, |
| where the <code>.</code> characters are replaced by <code>:</code> characters. For enumeration |
| literals, the non-absolute name of the enumeration literal is used, prefixed |
| with <code>:lit:</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No geometry is generated. When the generated Supremica file is opened in |
| Supremica, Supremica will perform auto layouting.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-initialization">Initialization</h5> |
| <div class="paragraph"> |
| <p>For the initial values of the variables, initialization predicates are |
| generated (e.g. <code>x == 3</code>). Earlier versions of Supremica that support |
| variables allowed deterministic initialization (only the initial value), and |
| non-deterministic initialization (initialization predicates). The most recent |
| version only allows non-deterministic initialization, which is why we generate |
| initialization predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-marking">Marking</h5> |
| <div class="paragraph"> |
| <p>In CIF, if none of the locations of an automaton are indicated as marked, the |
| automaton has no marked locations. In Supremica, if none of the locations of |
| an automaton are indicated as marked (<code>:accepting</code>), all locations of the |
| automaton are implicitly marked. When transforming a CIF automaton without any |
| marked locations, a warning is printed to the console to inform the user of |
| this difference.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In CIF, if none of the values of a variable is indicated as marked, the |
| variable has no marked values. In Supremica, if none of the values of |
| a variable is indicated as marked (<code>:accepting</code>), all values of the |
| variable are implicitly marked. When transforming a CIF variable without any |
| marked values, a warning is printed to the console to inform the user of |
| this difference.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Location pointer variables that are automatically generated, such as the ones |
| generated by the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF |
| transformation, have no marking and thus lead to warnings.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-invariants">Invariants</h5> |
| <div class="paragraph"> |
| <p>If the CIF model being transformed contains state invariants, an uncontrollable |
| <code>u_inv_bad</code> event is added to the Supremica module. It is renamed if the name |
| is not unique. A plant automaton named <code>inv_plant</code> (renamed if not unique) is |
| added as well. This plant enables the <code>u_inv_bad</code> event if and only if at |
| least one of the invariants doesn’t hold. A requirement automaton <code>inv_req</code> |
| (renamed if not unique) is added as well. The requirement disables the event |
| globally. Since blocking an uncontrollable plant event in a requirement is |
| forbidden, synthesis will prevent such blockage (by disabling controllable |
| events), thereby ensuring that the state invariants hold after synthesis.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-alphabets">Alphabets</h5> |
| <div class="paragraph"> |
| <p>In CIF, it is possible to explicitly specify the alphabet of an automaton. This |
| alphabet may include more events than occur on the edges of the automaton, |
| thereby globally disabling those additional events. Supremica automatically |
| determines the alphabet automatically, based on the events that occur on the |
| edges of the automaton, just like CIF does if no explicit alphabet is |
| specified. If a CIF automaton with 'additional' events is transformed, a self |
| loop is added to the initial state for each 'additional' event, with a |
| <code>false</code> guard (<code>0</code> in Supremica). This ensures that the event occurs on |
| an edge, and is thus part of the alphabet, but is not enabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-range-semantics">Range semantics</h5> |
| <div class="paragraph"> |
| <p>In CIF, if an update of an edge results in out of range values of variables, |
| the CIF specification is considered invalid, and the simulation will result |
| in a runtime error. In Supremica, the simulation does not result in a runtime |
| error, but instead the offending transition is disabled/forbidden.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-jumping-semantics">Jumping semantics</h5> |
| <div class="paragraph"> |
| <p>Consider the following CIF model:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton p: |
| controllable c_event; |
| disc int[0..3] v = 0; |
| |
| location loc1: |
| initial; |
| marked; |
| edge c_event do v := v + 1 goto loc2; |
| |
| location loc2: |
| edge c_event goto loc1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>There are two locations, and the edges allow for moving from one location to |
| the other. Both edges use the same event. Every odd transition (the first |
| transition, the third transition, etc), the value of variable <code>v</code> is |
| increased by one. Every even transition, the value of variable <code>v</code> is not |
| changed. After a few transitions, the simulation crashes due to overflow of |
| variable <code>v</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To ensure the same semantics in Supremica, such that for every even transition |
| the value of variable <code>v</code> does not change, the CIF model is modified by the |
| transformation, to the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton p: |
| controllable c_event; |
| disc int[0..3] v = 0; |
| |
| location loc1: |
| initial; |
| marked; |
| edge c_event do v := v + 1 goto loc2; |
| |
| location loc2: |
| edge c_event do v := v goto loc1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Users of the transformation don’t have to do anything themselves, as the tool |
| automatically adds the dummy assignments as needed. If the tool would not have |
| added such dummy assignments, then the value of variable <code>v</code> would have |
| been able to <em>jump</em> to any value (in its range <code>[0..3]</code>) for every even |
| transition, according to the Supremica semantics.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-simulation-validation-and-visualization-tools">Simulation, validation, and visualization tools</h3> |
| <div class="sect3"> |
| <h4 id="tools-cifsim-chapter-index">CIF simulator</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF simulator can be used to explore the |
| <a href="#tools-cifsim-traces-state-space">state space</a> of CIF specifications, either |
| interactively, or using a more automated approach. Powerful visualization |
| features allow for interactive visualization-based validation of the CIF |
| specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Basics</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-supported">Supported specifications</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-start">Starting the simulator</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-init">Initialization of the CIF specification</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-termination">Terminating the simulator</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-traces">Simulation of traces</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-repeated-simulation">Repeated simulation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Input/Output</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-index">Input modes</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-env-events">Environment events</a> (non-urgent events)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-index">Simulation output</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Advanced</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-options">Simulator options</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-performance">Simulation performance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-index">ODE solver</a> (integration and guard/event detection)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-java-compiler">Java compiler</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Miscellaneous</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-complete-mode">Complete mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-extfuncs">External user-defined functions</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-profiling">Profiling</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-distr-seeds">Stochastic distributions and seeds</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Developers</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-max-time-point-tol">Maximum time point tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-debug-gen-code">Debugging generated code</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-test-mode">Test mode</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-simulation-basics">Simulation basics</h4> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-supported">Supported specifications</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Input variables are currently not supported.</p> |
| </li> |
| <li> |
| <p>Time dependent <a href="#tut-data-chapter-stat-invariants">state invariants</a> are |
| not supported. This applies only to state invariants. |
| <a href="#tut-data-chapter-stat-evt-excl-invariants">State/event exclusion invariants</a> are supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Specifications with component definitions/instantiations are not natively |
| supported by the CIF simulator. Therefore, they are automatically eliminated |
| by the simulator, as a preprocessing step, using the CIF to CIF transformation |
| to <a href="#tools-cif2cif-chapter-elim-comp-def-inst">eliminate component definition/instantiation</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Automata with multiple possible initial locations and discrete variables with |
| multiple possible initial values (including <code>any</code>) are not supported, unless |
| additional <a href="#tools-cifsim-chapter-init">initialization</a> is provided.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The controllability of events is ignored by the simulator, as are marker |
| predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All automata are simulated as plants. That is, all automaton kinds are ignored |
| by the simulator. However, simulating requirements as plants may lead to |
| unexpected results. Therefore, the simulator prints warnings to the console, |
| whenever requirements are simulated. It is highly recommended to first apply |
| <a href="#tools-eventbased-chapter-supervisorsynthesis">supervisor synthesis</a> to the |
| specification, and simulate the resulting specification using the simulator. |
| Alternatively, apply verification to the specification, |
| <a href="#tools-cif2cif-chapter-remove-reqs">remove</a> the verified requirements, and |
| simulate the resulting specification using the simulator.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Similar to requirement automata, the simulator warns about simulation of |
| requirement invariants.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-start">Starting the simulator</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <b class="menuref">Simulate CIF specification…​</b>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <b class="menuref">Simulate CIF specification…​</b>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsim</code> tool in a ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifsim</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Once you start the simulator, an option dialog will appear, where you can |
| configure the simulation <a href="#tools-cifsim-chapter-options">options</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Instead of a CIF model (e.g. a <code>.cif</code> file), simulation can also be started |
| for a <a href="#tools-cifsim-chapter-repeated-simulation">compiled code file</a> (e.g. a |
| <code>.cifcode</code> file). For compiled code files, an additional option is |
| available. The simulator can also be started by double clicking such a file.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-init">Initialization of the CIF specification</h5> |
| <div class="paragraph"> |
| <p> |
| CIF supports <a href="#tut-data-chapter-discrete-variables">discrete variables</a> with |
| <a href="#lang-tut-data-discvar-init-multiple">multiple potential initial values</a>, |
| as well as discrete variables with an |
| <a href="#lang-tut-data-discvar-init-any">arbitrary initial value</a>. Furthermore, |
| CIF supports automata with |
| <a href="#lang-tut-data-init-preds-aut">multiple potential initial locations</a>. |
| The simulator however, needs to know how to initialize the specification. The |
| initial values of discrete variables, and the initial locations of automata, |
| can be specified using the |
| <b class="menuref">CIF specification initialization</b> |
| option |
| (<b class="menuref">Simulator</b> |
| category). Initialization can be provided using the |
| option, per discrete variable or automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For a discrete variable, initialization is of the form <code>var:value</code>, where |
| <code>var</code> is the absolute name of a discrete variable, and <code>value</code> is a CIF |
| <a href="#lang-tut-values-types-values-exprs-literal">literal</a> that represents a |
| valid initial value for the variable. Providing an initialization for a |
| discrete variable with a |
| <a href="#tut-functions-chapter-functions-as-values">function type</a> or a |
| <a href="#tut-stochastics-chapter-intro">distribution</a> type, is not supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For an automaton, initialization is of the form <code>aut:loc</code>, where <code>aut</code> is |
| the absolute name of an automaton, and <code>loc</code> is the name of a location of |
| that automaton. Providing an initialization for an automata with only one |
| nameless location, is not supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is not allowed to provide multiple initializations for a single variable or |
| automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If insufficient initializations are provided, variables and automata may not be |
| initialized. That is, the simulator may not be able to choose between the |
| multiple potential initial values or locations. The simulator will report such |
| problems, indicating the specification is |
| <a href="#tools-cifsim-chapter-supported">unsupported</a> without additional or alternative |
| initializations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is also possible that initializations in the CIF specification itself are |
| incomplete or conflicting, the provided initializations are conflicting, or |
| their combination is conflicting. Furthermore, initializations may be provided |
| for values or locations that are not potential initial values or locations. In |
| all such cases, initialization fails. The simulator will report such problems, |
| providing detailed information about what caused the initialization failure.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-termination">Terminating the simulator</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator can terminate for various reasons. This page explains each |
| of them, as well as some other information related to termination of the |
| simulator.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-initialization-failure">Initialization failure</h6> |
| <div class="paragraph"> |
| <p>If <a href="#tools-cifsim-chapter-init">initialization</a> of the specification fails, |
| the simulation will terminate immediately.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-deadlock">Deadlock</h6> |
| <div class="paragraph"> |
| <p>If simulation results in deadlock, no more transitions are possible, and the |
| simulation will terminate.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulation does not immediately terminate when deadlock occurs, if an |
| interactive <a href="#tools-cifsim-input-chapter-index">input mode</a> is used and |
| <a href="#tools-cifsim-input-chapter-history">history</a> is enabled. Instead, the user is |
| asked whether to terminate the simulation, |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> one or more transitions, or |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-termination-endtime">Simulation end time</h6> |
| <div class="paragraph"> |
| <p>Using the |
| <b class="menuref">Simulation end time</b> |
| option (<b class="menuref">Simulator</b> |
| category), the end time of the simulation can be configured. By setting a |
| simulation end time, you ensure that when the value of variable <code>time</code> |
| reaches that value, the simulation terminates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default the simulation end time is set to 'infinite', which means that |
| simulation termination is not limited by a simulation end time. Settings a |
| simulation end time also limits the <a href="#tools-cifsim-solver-chapter-endtime-maxdelay">maximum duration of a time transition</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulation does not immediately terminate when the configured end time is |
| reached, if an interactive <a href="#tools-cifsim-input-chapter-index">input mode</a> is |
| used and <a href="#tools-cifsim-input-chapter-history">history</a> is enabled. Instead, the |
| user is asked whether to terminate the simulation, |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> one or more transitions, or |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-runtime-error">Runtime error</h6> |
| <div class="paragraph"> |
| <p>If simulation results in a runtime error, the simulation will terminate |
| immediately.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-end-of-trace-file">End of trace file</h6> |
| <div class="paragraph"> |
| <p>If the <a href="#tools-cifsim-input-chapter-trace">trace input mode</a> is used, and no |
| more commands are available in the trace file, the simulation will terminate |
| immediately.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-user-requested-termination">User-requested termination</h6> |
| <div class="paragraph"> |
| <p>The user can manually request termination of the simulation in several ways.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Termination requests have no effect while the simulator interactively asks |
| for input from the <a href="#tools-cifsim-input-chapter-console">console</a> or via the GUI |
| of the <a href="#tools-cifsim-input-chapter-gui">interactive GUI input component</a>. |
| However, once input is provided via the console and <kbd>ENTER</kbd> is pressed, or |
| a choice is made via the GUI, the termination request will be processed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Termination requests issued between |
| <a href="#tools-cifsim-output-realtime-frames">intermediate frames</a> are delayed |
| until the next intermediate frame.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-interactive-console-input">Interactive console input</h7> |
| <div class="paragraph"> |
| <p>Termination of the simulation can be requested, when using the interactive |
| <a href="#tools-cifsim-input-chapter-console">console</a> input mode, by typing <code>q</code> |
| and pressing <kbd>ENTER</kbd>, whenever the simulator interactively asks for input |
| via the console.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-interactive-gui-input">Interactive GUI input</h7> |
| <div class="paragraph"> |
| <p>Termination of the simulation can be requested, when using the interactive |
| <a href="#tools-cifsim-input-chapter-gui">interactive GUI input mode</a>, by closing the |
| GUI of the interactive GUI input component, when the simulator asks for input |
| via that GUI.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-applications-view">Applications view</h7> |
| <div class="paragraph"> |
| <p>The <em>Applications</em> view has several termination features that may terminate |
| any application, including the CIF simulator. See the documentation for |
| that view, for details.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-console-termination-button">Console termination button</h7> |
| <div class="paragraph"> |
| <p>Simulation can be terminated at any time, by using the <b class="menuref">Terminate</b> |
| button (<span class="image"><img src="./tools/cifsim/terminate_button.png" alt="terminate button"></span>), located at the upper right corner of the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Note however that if the console does not have the focus, this button may not |
| be visible. If the button is not visible, click somewhere in the console to |
| make the button appear. If even then the button is still not available, it may |
| still appear if you <b class="menuref">Maximize</b> the console. Due to these issues, use |
| of the termination features of the <em>Applications</em> view is recommended over |
| using the <b class="menuref">Terminate</b> button of the console. See the documentation for |
| that view, for details.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-closing-last-real-time-visualizer">Closing last real-time visualizer</h7> |
| <div class="paragraph"> |
| <p>If the last remaining |
| <a href="#tools-cifsim-output-realtime-outcomp">real-time output component</a> |
| (visualizer) is closed by the user, the simulator will be asked to terminate as |
| soon as possible.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-termination-confirm">Confirming termination</h6> |
| <div class="paragraph"> |
| <p>When simulating within Eclipse, all |
| <a href="#tools-cifsim-output-components">visualizers</a> remain open, after the |
| simulation has terminated. This allows you to observe the final state of the |
| simulation, before manually closing the visualizers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When simulating on the command line (outside of Eclipse), termination of the |
| simulator means that the visualizers are also closed. To allow you to observe |
| the final state of the simulation, you are asked to confirm termination of the |
| simulator, and therefore closing of the visualizers, by pressing <kbd>ENTER</kbd> |
| at the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, you are only asked to confirm termination of the simulator when |
| simulating on the command line (outside of Eclipse), at least one visualizer |
| is visible at the end of the simulation, simulation did not result in a runtime |
| error, and <a href="#tools-cifsim-chapter-test-mode">test mode</a> is disabled. The |
| <b class="menuref">Ask to confirm simulator termination</b> |
| option (<b class="menuref">Simulator</b> |
| category) can be used to configure whether the simulator asks the user to |
| confirm termination of the simulator, terminate automatically, or decides by |
| itself whether to ask the user for confirmation or terminate automatically. The |
| latter (letting the simulator decide by itself) is the default.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-traces">Simulation of traces</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator simulates one particular trace through the state space of |
| the specification. To better understand what the previous sentence means, this |
| page further explains each of those concepts.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-traces-state">State</h6> |
| <div class="paragraph"> |
| <p>Automata consist of one or more locations. However, at any time, an automaton |
| can only be in <em>one</em> of its locations. This location is called the <em>current</em> |
| or <em>active</em> location. The current location of an automaton is also called the |
| <em>state</em> of the automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Similar to having multiple locations in automata, variables usually have many |
| possible values. However, similar to automata having only one current location, |
| variables can not have two values at the same time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The current location of each of the automata (i.e. the states of the automata), |
| together with the current values of the variables (all discrete and continuous |
| variables, including variable <code>time</code>), is called the <em>state</em> of the |
| specification. The state of the specification (or simply 'the state'), is |
| all the information that needs to be maintained about the history of the |
| simulation, going forward.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton button: |
| event pushed, released; |
| |
| location Released: |
| initial; |
| edge pushed goto Pushed; |
| |
| location Pushed: |
| edge released goto Released; |
| end |
| |
| automaton machine: |
| event producing, produced; |
| |
| location Idle: |
| initial; |
| edge producing when button.Pushed goto Producing; |
| |
| location Producing: |
| edge produced goto Idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We have two automata, <code>button</code> and <code>machine</code>. Pushing the button (event |
| <code>button.pushed</code>) turns on the machine. Releasing the button (event |
| <code>button.released</code>) turns it off. Initially, the machine is <code>Idle</code>. While |
| the button is pushed (location <code>button.Pushed</code> is the current location of |
| automaton <code>button</code>), the machine can start to create a product (event |
| <code>machine.producing</code>). Once the machine has produced a product (event |
| <code>machine.produced</code>), the machine becomes idle again. Note that once the |
| machine starts producing a product, it always finishes producing it, even if it |
| is turned off in the mean time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The state of automaton <code>button</code> is either of its locations: |
| <code>button.Released</code> or <code>button.Pushed</code>. Similarly, the state of automaton |
| <code>machine</code> is <code>machine.Idle</code> or <code>machine.Producing</code>. Initially, the system |
| is in state <code>button: Released, machine: Idle, time: 0.0</code>. For the remainder of |
| variable <code>time</code> will omitted from the state, for brevity only. Furthermore, |
| also for brevity only, we’ll omit the names of the automata. Therefore, the |
| initial state is <code>Released, Idle</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-traces-state-space">State space</h6> |
| <div class="paragraph"> |
| <p>The <em>state space</em> of a specification consists all the possible states of the |
| specification, connected by the transitions via which they can be reached.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the example above, the state space is (event names are abbreviated):</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/state_space.png" alt="state space"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Since both automata can be in two states, the state space in this case consists |
| of four states. From the initial state (the upper left state), the button can |
| be pushed, leading to the upper right state, where the button is pushed, while |
| the machine has not yet started to produce a product. The machine can then |
| start to produce a product (going to the lower right state). If however the |
| button is released before the machine can respond by starting to produce a |
| product, we go back to the upper left state. When the machine finishes |
| creation of the product, we go from the lower right state back to the upper |
| right state. If on the other hand the button is released, while the product is |
| still being produced, we go from the lower right state to the lower left state. |
| If we then push the button again, we go back to the lower right state. If |
| instead the button is not pushed, and the machine finishes producing the |
| product, we go from the lower left state back to the upper left state.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-traces-traces">Traces</h6> |
| <div class="paragraph"> |
| <p>A <em>trace</em> is a sequence of transitions, from the initial state, through the |
| state space.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In state spaces, most states usually have multiple outgoing transitions. This |
| means there is <em>choice</em>. That is, it is possible to choose to which next state |
| to go. Furthermore, it is usually possible to keep taking transitions forever, |
| which means we can have infinite traces.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the example above, some of the possible traces are shown below. Only the |
| first five transitions of the traces are shown. State names are abbreviated, |
| to the first letters of the names of the locations.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>RI |
| → <code>pushed</code> → PI → <code>released</code> → RI |
| → <code>pushed</code> → PI → <code>released</code> → RI |
| → <code>pushed</code> → PI → …​</p> |
| </li> |
| <li> |
| <p>RI |
| → <code>pushed</code> → PI → <code>producing</code> → PP |
| → <code>produced</code> → PI → <code>producing</code> → PP |
| → <code>produced</code> → PI → …​</p> |
| </li> |
| <li> |
| <p>RI |
| → <code>pushed</code> → PI → <code>producing</code> → PP |
| → <code>released</code> → RP → <code>produced</code> → RI |
| → <code>pushed</code> → PI → …​</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In the first trace, we push the button, release it, push it again, release it, |
| and push it again, all without ever starting to produce a product. This traces |
| shows us what happens if the button is constantly being pushed and released, |
| as quickly as possible, without the machine being able to respond to this, by |
| starting to produce a product.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the second trace, we push the button, we start to produce a product, we |
| finish producing it, start to produce another product (the button is still |
| pushed), finish producing the second product, and start to produce a third |
| product. This is a trace of a typical usage scenario, where we start the |
| machine, and the machine keeps running.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the third trace, we push the button, start to produce a product, release the |
| button before the product is finished, finish producing the product, and push |
| the button again. This trace is another typical usage scenario, which also |
| includes turning off the machine.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-traces-simulation">Simulation</h6> |
| <div class="paragraph"> |
| <p>As stated at the top of the page: <em>'The CIF simulator simulates one |
| particular trace through the state space of the specification'</em>. To see why |
| this is the case, we take a look at the main simulation loop, as used by the |
| simulator:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Calculate the initial state, and set it as the current state.</p> |
| </li> |
| <li> |
| <p>Forever, do:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>If the user-provided simulation end time is reached, stop simulation.</p> |
| </li> |
| <li> |
| <p>Calculate the possible transitions for the current state.</p> |
| </li> |
| <li> |
| <p>If no transitions are possible (deadlock), stop simulation.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-index">Choose</a> one of the possible transitions.</p> |
| </li> |
| <li> |
| <p>Take the chosen transition, and set its target state as the new current |
| state.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>While this main simulation loop is simplified with respect to the real |
| implementation, it gives some insight into the inner workings of the simulator. |
| The simulator keeps taking transitions. Once a transition is taken, the current |
| state is updated to the target state of the transition. This means that the |
| other possible transitions (the ones that were not chosen), are not taken. |
| Therefore, if we want to take a different transition, we should restart |
| simulation from the initial state, and make different choices. That is, if we |
| want to simulate a different trace, we perform another simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-traces-validation">Validation</h6> |
| <div class="paragraph"> |
| <p>The simulator can be used to gain confidence in the correctness of the |
| specification. By simulating various traces, we can observe what happens in |
| different scenarios (use cases). Since the number of traces if often infinite, |
| covering the entire state space, and all possible traces, is impossible. |
| However, by wisely choosing the traces we simulate, we can cover a large part |
| of the state space.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It should be clear by now, that simulating a single trace is almost never |
| enough to conclude that your specification is 'correct'. Different traces lead |
| to different behavior, and only by testing enough traces, and thus covering |
| enough of the system’s behavior, can you conclude that your specification |
| works as expected (for those traces).</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-repeated-simulation">Repeated simulation</h5> |
| <div class="paragraph"> |
| <p> |
| |
| When simulating a CIF model, the simulator reads the CIF file, checks it for |
| validity, generates |
| <a href="http://oracle.com/java">Java</a> |
| code, |
| <a href="#tools-cifsim-chapter-java-compiler">compiles</a> the code, and uses the compiled |
| code using the actual simulation. All of this takes a bit of time, or even |
| quite some time, depending on the size of the model. This situation is not |
| ideal for repeated simulations, for instance when trying different scenarios |
| or use cases, when simulating with different |
| <a href="#tools-cifsim-chapter-options">options</a>, or when repeating simulations with |
| various different <a href="#tools-cifsim-chapter-init">initializations</a> or due to |
| <a href="#tut-stochastics-chapter-intro">stochastic</a> behavior. The startup time for |
| the first simulation is also present for the second simulation, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It would be much better to generate and compile the code just once, and then |
| simulate multiple times using the already compiled code, significantly reducing |
| the startup time of the simulations. This is especially useful for automated |
| repeated simulations, where the same simulation model, either with different |
| options (for instance different initializations) or with the same options for a |
| model with stochastics, is simulated multiple times and the results of |
| simulation are for instance compared or aggregated in some way.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-repeated-sim-compile-once">Compiling just once</h6> |
| <div class="paragraph"> |
| <p>The simulator can be used to generate code and compile it only once. By |
| enabling the <em>Compile only</em> option (<em>Compiler</em> category), the simulator will |
| perform all steps needed to generate and compile the code, and will then save |
| the compiled code to a file. After saving the file, the simulator will |
| terminate, not simulating the model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, the input file name (e.g. <code>some_file.cif</code>) is used to construct |
| the name of the simulator compiled Java code file, by removing the <code>.cif</code> |
| file extension if present, and adding a <code>.cifcode</code> file extension to it (e.g. |
| resulting in <code>some_file.cifcode</code>). It is possible to change this file name |
| by using the <em>Compiled code file</em> option (<em>Compiler</em> category). If used, it |
| specifies the absolute or relative local file system path to the compiled Java |
| code file.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The compiled code file can be put in any directory. It does not have to be in |
| the same directory as the original CIF model. However, make sure that any |
| additional files, such as <a href="#tools-cifsim-output-svgviz-chapter-svg">SVG images</a> |
| for <a href="#tools-cifsim-output-svgviz-chapter-index">visualization</a>, remain in their |
| original locations. They will be resolved relative to the original location of |
| the CIF model that was compiled.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-simulating-using-a-compiled-code-file">Simulating using a compiled code file</h6> |
| <div class="paragraph"> |
| <p>There are several ways to start simulation with a compiled code file. In fact, |
| all the ways to <a href="#tools-cifsim-chapter-start">start</a> simulation for normal CIF |
| models (e.g. <code>.cif</code> files), apply to compiled code files (e.g. <code>.cifcode</code> |
| file) as well. The simulator checks whether the input file name ends with |
| <code>.cifcode</code> and then loads the compiled code file, instead of treating the |
| input model as CIF model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Alternatively, a <code>.cifcode</code> file can be double clicked in the Eclipse |
| 'Project Explorer' tab or 'Package Explorer' tab, to immediately |
| start simulation. An option dialog is shown to configure any simulator |
| <a href="#tools-cifsim-chapter-options">options</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A warning is printed to the console if the compiled code file was generated |
| by a different version of the simulator than the one used to simulate it. |
| Ignoring the warning may lead to unexpected simulation results, or even |
| simulator crashes.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-option-effects-and-priorities">Option effects and priorities</h6> |
| <div class="paragraph"> |
| <p>Most simulator <a href="#tools-cifsim-chapter-options">options</a> have no effect when the |
| <em>Compile only</em> option (<em>Compiler</em> category) is enabled, as after code is |
| generated, compiled, and saved to a file, the simulator terminates, and no |
| actual simulation is performed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <em>Compile only</em> option (<em>Compiler</em> category) has no effect when |
| <a href="#tools-cifsim-chapter-debug-gen-code">debugging generated code</a>, by enabling |
| the <em>Load debug code</em> option (<em>Simulator</em> category).</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-example">Example</h6> |
| <div class="paragraph"> |
| <p>As an example, consider the following CIF model in file <code>machine.cif</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event enter; |
| event processed; |
| event exit; |
| |
| automaton machine: |
| disc int count = 0; |
| disc real process_time; |
| disc dist real d = normal(10, 7); |
| cont t der 1.0; |
| |
| location waiting: |
| initial; |
| edge enter do (process_time, d) := sample d, t := 0 goto processing; |
| |
| location processing: |
| edge processed when t >= process_time goto done; |
| |
| location done: |
| edge exit do count := count + 1 goto waiting; |
| end |
| |
| print machine.count for final;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The model consists of a <code>machine</code> that processes products. Initially, the |
| machine is <code>waiting</code>. Once a product enters the system, the machine will |
| start <code>processing</code>. Once the product is <code>processed</code>, the machine is |
| <code>done</code> and will be <code>waiting</code> for the next product to <code>enter</code>. The time it |
| takes to process a product varies with each product. A |
| <a href="http://en.wikipedia.org/wiki/Normal_distribution">normal distribution</a> |
| with |
| a mean of <code>10</code> and a variance of <code>7</code> is used to model the varying |
| processing times.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print declaration</a> at the |
| end of the model is used to <a href="#tools-cifsim-output-print-chapter-index">print</a> |
| the number of processed products at the end of the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following ToolDef <a href="#tools-scripting-chapter-intro">script</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim("machine.cif --compile-only=on"); |
| |
| rmfile("out.txt", force=true); |
| |
| for x in range(1000): |
| string args = "machine.cifcode -i auto -a first -t 100 -o print"; |
| cifsim(args, stdout="out.txt", appendOut=true); |
| end |
| |
| double minimum = 9999; |
| double maximum = -9999; |
| for line in readlines("out.txt"): |
| double value = <double>line; |
| minimum = min(minimum, value); |
| maximum = max(maximum, value); |
| end |
| |
| outln("Minimum: %.2f", minimum); |
| outln("Maximum: %.2f", maximum);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>import</code> statement makes the CIF tools available. The first <code>cifsim</code> |
| command generates code for the <code>machine.cif</code> model, compiles it, and saves it |
| to <code>machine.cifcode</code>. The <code>rmfile</code> command removes the <code>out.txt</code> file, in |
| case it was left over from a previous run of the script.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The body of the <code>for</code> statement is executed <code>1000</code> times. Each time, the |
| <code>cifsim</code> command is used to simulate the model, using the already compiled |
| code in <code>machine.cifcode</code>. The simulation uses |
| <a href="#tools-cifsim-input-chapter-automatic">automatic mode</a> due to <code>-i auto</code>, |
| always chooses the <a href="#tools-cifsim-input-automatic-trans">first</a> available |
| transition due to <code>-a first</code>, <a href="#tools-cifsim-termination-endtime">ends</a> |
| at time <code>100</code> due to <code>-t 100</code>, and only |
| <a href="#tools-cifsim-output-chapter-normal">outputs</a> text for print declarations due |
| to <code>-o print</code>. The output of the simulation is not written to the console, |
| but to <code>out.txt</code> due to the use of the <code>stdout</code> parameter of the |
| <code>cifsim</code> tool. The <code>appendOut</code> parameter is enabled to ensure that the |
| output of each simulation is appended (added) to the <code>out.txt</code> file instead |
| of overwriting the file for each simulation. After the simulations, the |
| <code>out.txt</code> file will contain the number of processed products for each of the |
| simulation experiments.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The remainder of the script computes the minimum and maximum number of products |
| (minimum and maximum throughput) of the machine, as observed from the |
| experiments. Both the <code>minimum</code> and <code>maximum</code> are initialized. Then each |
| line of the <code>out.txt</code> file is processed. The numeric value is obtained by |
| casting the text of the line to a <code>double</code> number. Then the <code>minimum</code> and |
| <code>maximum</code> are updated as needed. After the minimum and maximum are |
| calculated, they are printed to the console as floating point numbers with two |
| digits after the decimal mark.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The output of the execution of the script could look like this, but may vary |
| given that stochastics are used:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">Minimum: 7.00 |
| Maximum: 12.00</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-applications-view-2">Applications view</h6> |
| <div class="paragraph"> |
| <p>The <em>Applications</em> view shows the current status |
| of each running application. For repeated simulation, lots of applications may |
| be started in a short period of time. Also, a lot of status updates need to |
| be processed by the view in a short amount of time. This may lead to many |
| updates of the GUI of the <em>Applications</em> view, which could potentially reduce |
| the responsiveness of Eclipse, and decrease the performance of the simulation. |
| If you experience such problems, simply close the <em>Applications</em> view while |
| running a repeated simulation.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-simulation-inputoutput">Simulation input/Output</h4> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-input-chapter-index">Input modes</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The CIF simulator simulates <a href="#tools-cifsim-chapter-traces">traces</a> through the |
| <a href="#tools-cifsim-traces-state-space">state space</a> of a specification. If |
| multiple transitions are possible, a choice must be made. The simulator defers |
| this choice to an <em>input component</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The primary responsibility or an input component is to choose the transition to |
| take, from the given possible transitions, calculated for the current |
| <a href="#tools-cifsim-traces-state">state</a>. If the chosen transition is a time |
| transition, the input component must also decide the amount of time to delay.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The input component to use for the simulation, depends on the <em>input mode</em>, |
| which can be configured via the |
| <b class="menuref">Input mode</b> |
| option |
| (<b class="menuref">Input</b> |
| category). The simulator has several input modes:</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-console">Interactive console input mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-gui">Interactive GUI input mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-automatic">Automatic input mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-trace">Trace input mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-svg-chapter-index">SVG input mode</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only one input mode, and thus one input component, can be used for each |
| simulation. By default, the <em>GUI input mode</em> is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following information on other topics, related to input modes, is |
| available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-semi-automatic">Semi-automatic mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-history">State history</a> (reset, undo)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-console">Interactive console input mode</h6> |
| <div class="paragraph"> |
| <p> |
| |
| In the interactive console input mode, the simulator interactively asks the |
| user to choose the transitions to take, etc. The questions are asked via text |
| printed to the console. The user enters his/her choice via the console as well.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-a-transition-to-take">Choosing a transition to take</h7> |
| <div class="paragraph"> |
| <p>The following is an example of the simulator interactively asking the user to |
| choose a possible transition:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">Possible transitions: |
| #1: event machine1.c_start |
| #2: event machine2.c_start |
| #3: delay for (0 .. 100.0] |
| |
| Select a transition ([1..3]). Enter q to quit. Enter h for help and additional commands. Confirm with <ENTER>:</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, three possible transitions are given, numbered <code>1</code> to <code>3</code>. For your |
| convenience, they are sorted alphabetically on the names of the events, with |
| event <code>tau</code> always at the end, just before time transitions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The user should enter a command, and confirm that choice by pressing |
| <kbd>ENTER</kbd>. Several command are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Entering a number in the given range, corresponding to the transition with |
| that number, will result in that specific transition being taken. So, |
| entering <code>2</code> and pressing <kbd>ENTER</kbd>, will result in the simulator taking |
| the transition for event <code>machine2.c_start</code>. The valid choices for the |
| transitions are indicated by the range <code>[1..3]</code>. In case of an invalid |
| number, an error message is printed to the console, and the user can choose |
| again.</p> |
| </li> |
| <li> |
| <p>Entering nothing, and only pressing <kbd>ENTER</kbd>, defaults to choosing |
| transition <code>1</code>.</p> |
| </li> |
| <li> |
| <p>Entering <code>r</code> or <code>R</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> the simulation to the |
| initial state. If reset is not enabled, or not possible for the current |
| state, an error message is printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>u</code> or <code>U</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> one transition. If undo is |
| not enabled, or not possible for the current state, an error message is |
| printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>u <n></code> or <code>U <n></code>, with <code><n></code> a positive number, and |
| confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> <code>n</code> transitions. If undo is |
| not enabled, it is not possible to undo <code>n</code> transitions for the current |
| state, an error message is printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>q</code> or <code>Q</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-chapter-termination">terminate</a> the simulation.</p> |
| </li> |
| <li> |
| <p>Entering <code>h</code> or <code>H</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| result in the simulator printing a short help text to the console, that |
| shows the available commands. The user is then again asked to choose.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If a choice is made that is invalid or is not available for the current state, |
| an error message is printed to the console, and the user is asked to make an |
| other choice.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-a-time-transition-duration">Choosing a time transition duration</h7> |
| <div class="paragraph"> |
| <p>If the user chooses a time transition (choice <code>3</code> in the above example), the |
| simulator subsequently asks for the duration of the time delay:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">Select a duration from (0 .. 100.0]. Empty choice equals maximum delay. Enter q to quit. Confirm with <ENTER>:</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the duration of the time delay is to be entered. In this case, the |
| duration must be in the <code>(0 .. 100.0]</code> interval. That is, it must be larger |
| than zero, and less or equal to <code>100.0</code>. Both integer and real values are |
| allowed. As before, confirm with <kbd>ENTER</kbd>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Pressing <kbd>ENTER</kbd> without having entered anything, defaults to the maximum |
| delay, which in this case is <code>100.0</code>. Entering <code>q</code> or <code>Q</code>, and confirming |
| that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-chapter-termination">terminate</a> the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a choice is made that is invalid, an error message is printed to the |
| console, and the user is asked to make an other choice.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-between-termination-or-going-back">Choosing between termination or going back</h7> |
| <div class="paragraph"> |
| <p>If no transitions are possible, for instance due to |
| <a href="#lang-tut-time-deadlock">deadlock</a> or reaching the |
| <a href="#tools-cifsim-termination-endtime">end-user provided simulation end time</a>, |
| the simulator may interactively ask the |
| user to choose between termination of the simulation, resetting the simulation |
| to the initial state, or undoing some transitions. This choice is only |
| presented if either reset or undo is enabled, as otherwise there is no choice |
| to make.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following is an example of the simulator interactively asking the user to |
| choose between termination and going back:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">Simulation resulted in deadlock. Enter q to quit. Enter h for help and additional commands. Confirm with <ENTER>:</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The user should enter a command, and confirm that choice by pressing |
| <kbd>ENTER</kbd>. Several command are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Entering <code>r</code> or <code>R</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> the simulation to the |
| initial state. If reset is not enabled, or not possible for the current |
| state, an error message is printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>u</code> or <code>U</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> one transition. If undo is |
| not enabled, or not possible for the current state, an error message is |
| printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>u <n></code> or <code>U <n></code>, with <code><n></code> a positive number, and |
| confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> <code>n</code> transitions. If undo is |
| not enabled, it is not possible to undo <code>n</code> transitions for the current |
| state, an error message is printed and the user can choose again.</p> |
| </li> |
| <li> |
| <p>Entering <code>q</code> or <code>Q</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| <a href="#tools-cifsim-chapter-termination">terminate</a> the simulation.</p> |
| </li> |
| <li> |
| <p>Entering <code>h</code> or <code>H</code>, and confirming that by pressing <kbd>ENTER</kbd>, will |
| result in the simulator printing a short help text to the console, that |
| shows the available commands. The user is then again asked to choose.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If a choice is made that is invalid or is not available for the current state, |
| an error message is printed to the console, and the user is asked to make an |
| other choice.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-semi-automatic-mode">Semi-automatic mode</h7> |
| <div class="paragraph"> |
| <p>By default, in the interactive console input mode, the user is asked to choose, |
| even if for instance there is only one possible transition. Having to choose |
| for every transition can become tiresome. To reduce the number of situations |
| where a choice is required, the |
| <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a> mode is available.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-gui">Interactive GUI input mode</h6> |
| <div class="paragraph"> |
| <p> |
| |
| In the interactive GUI input mode, the simulator interactively asks the user to |
| choose the transitions to take, etc. Choices are presented using a GUI |
| (Graphical User Interface). The user makes choices via the GUI as well.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-layout">Layout</h7> |
| <div class="paragraph"> |
| <p>The following is an example of the simulator interactively asking the user to |
| choose a possible transition:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_basic.png" alt="interactive gui basic"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The events of the system are vertically listed, in alphabetical order, with |
| event <code>tau</code> at the end, just before the |
| <b class="menuref">time delay</b>, |
| and |
| <b class="menuref">reset</b> |
| and |
| <b class="menuref">undo</b>. |
| If there are too many elements to fit |
| vertically, more columns are used. If things still don’t fit, a horizontal |
| scroll bar is shown.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-gui-availability">Availability</h7> |
| <div class="paragraph"> |
| <p>Choices for events are only present if the events are interactively chosen. If |
| they are (semi-)automatically chosen, they are not shown in the GUI. Similarly, |
| choices for |
| <b class="menuref">time delay</b> |
| are only shown if time transitions or their |
| durations are interactively chosen. For more information, see the |
| <a href="#tools-cifsim-input-gui-semiauto">Semi-automatic mode</a> section below.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For event <code>tau</code>, the choices are additionally only shown if there is at least |
| one <code>tau</code> edge in the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The choice to |
| <b class="menuref">reset</b> |
| the simulation is only shown if |
| <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation is enabled. |
| Similarly, the choice to |
| <b class="menuref">undo</b> |
| transitions is only shown if |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> is enabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If none of the choices are to be shown in the GUI, the GUI itself is not shown |
| at all.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-buttons">Buttons</h7> |
| <div class="paragraph"> |
| <p>For each element, there are two buttons. The left button shows the name of the |
| event, or a description of the choice (e.g. |
| <b class="menuref">time delay</b>, |
| <b class="menuref">reset</b>), |
| and can be used to quickly choose a transition. The second |
| button shows an arrow, and can be used to show a popup menu, presenting |
| additional choices. What exactly is chosen when clicking the button, and what |
| exactly is shown in the popup menu, differs for the different choices. The |
| sections below provide further details.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If no choice needs to be made at the moment, all buttons are disabled. If a |
| choice needs to be made, only those buttons that represent active choices are |
| enabled.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-styling">Styling</h7> |
| <div class="paragraph"> |
| <p>For <a href="#tools-cifsim-chapter-env-events">environment</a> (non-urgent) events, the |
| label of the left button is italic. For non-environment (urgent) events, as |
| well as for non-event choices, the label uses a normal font.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Before each element a colored box is shown. The box is gray while that |
| particular choice is not available. If choices are available, the box is green |
| for <a href="#lang-tut-extensions-synthesis-evtctrl">controllable</a> events, red for |
| <a href="#lang-tut-extensions-synthesis-evtctrl">uncontrollable</a> events, blue for |
| other events, and black for everything else (<b class="menuref">time delay</b>, |
| <b class="menuref">reset</b>, |
| and |
| <b class="menuref">undo</b>). |
| The text of the left button has |
| the same color as the box. The colors help to quickly identify elements with |
| possible choices.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-labels">Labels</h7> |
| <div class="paragraph"> |
| <p>Between the buttons, a label may be shown, to provide more details. When the |
| label is shown, and what text is shown, differs for the different choices. The |
| sections below provide further details.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the above image, the system has five events, besides the <code>tau</code> event. The |
| simulator asks the user to choose between a transition for event |
| <code>Switch.u_on</code> and a time transition.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-an-event-transition">Choosing an event transition</h7> |
| <div class="paragraph"> |
| <p>For an event, the first button makes it possible to quickly choose a transition |
| for that event. If clicked, the possible transitions are filtered to those for |
| the chosen event, and the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a> is asked to |
| make the actual choice, based on its own configuration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If multiple transitions are possible for a single event, the number of possible |
| transitions is displayed as label between the two buttons for that event. The |
| following image shows an example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_event.png" alt="interactive gui event"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this example, two transitions are possible for event <code>b2m</code>. By clicking |
| the button labeled with <code>b2m</code>, the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a> is asked to |
| choose between the two transitions, based on its own configuration. By clicking |
| the arrow button, a popup menu is shown, showing the two transitions. The popup |
| menu allows manually choosing which transition to take, by clicking the menu |
| item of the transition you wish to take.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-a-time-transition-and-duration">Choosing a time transition and duration</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="button">time delay</b> |
| button makes it possible to quickly choose the time |
| transition. By default the maximum allowed delay duration will be used. This |
| duration is displayed as label between the two buttons, in short form with |
| three significant digits. By clicking the arrow button, additional options |
| become available. These options also show the complete durations. The following |
| image shows an example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_time.png" alt="interactive gui time"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>At most <code>0.30000000000000066</code> units of time can pass (<code>0.300</code> in short |
| form). The first option is to choose a custom duration. The second option is |
| to choose that maximum duration, similar to clicking the |
| <b class="menuref">time delay</b> |
| button. The following image shows the dialog that is presented to the user to |
| enter the custom duration:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_duration.png" alt="interactive gui duration"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By entering an integer or real number for the duration, that exact amount of |
| time units will pass, after clicking the |
| <b class="button">OK</b> |
| button. If the |
| <b class="button">Cancel</b> |
| button is clicked instead, the choice is canceled, and the |
| user is again free to choose between all available choices.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-to-reset-the-simulation">Choosing to reset the simulation</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="button">reset</b> |
| button makes it possible to |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> the simulation to the initial |
| state. The popup menu that can be shown by clicking on the arrow button, has |
| only one option, which the same effect as clicking the button. The following |
| image shows the popup menu:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_reset.png" alt="interactive gui reset"> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-choosing-to-undo-some-transitions">Choosing to undo some transitions</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="button">undo</b> |
| button makes it possible to |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> a single transition, and go back |
| to the state just prior to that transition. The number of transitions that can |
| be undone, is displayed as label between the two buttons.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Clicking the arrow button shows a popup menu with additional options. Menu |
| items are present to undo 1 transition, to undo 2 transitions, to undo 3 |
| transitions, etc, for as many transitions as can be undone. The following image |
| shows an example with two transitions that can be undone:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_undo2.png" alt="interactive gui undo2"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>At most 10 such menu items are shown. If more than 10 transitions can be |
| undone, an additional choice is present, that allows entering a custom number |
| of transitions to undo. The following image shows an example with 12 |
| transitions that can be undone:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_undo12.png" alt="interactive gui undo12"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Selecting that last option will present the user with a dialog, to select the |
| number of transitions to undo:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/interactive_gui_undo_count.png" alt="interactive gui undo count"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The number of transitions needs to be entered as a positive number, within the |
| given range. Clicking the |
| <b class="button">OK</b> |
| button will undo the requested number |
| of transitions. If the |
| <b class="button">Cancel</b> |
| button is clicked instead, the choice |
| is canceled, and the user is again free to choose between all available |
| choices.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-gui-semiauto">Semi-automatic mode</h7> |
| <div class="paragraph"> |
| <p>By default, in the interactive GUI input mode, the user is asked to choose, |
| even if for instance there is only one possible transition. Having to choose |
| for every transition can become tiresome. To reduce the number of situations |
| where a choice is required, the |
| <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a> mode is available.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Choices that are no longer available due to them being automatically chosen by |
| enabling semi-automatic mode, are not shown in the GUI of the interactive GUI |
| input mode. See also the <a href="#tools-cifsim-input-gui-availability">Availability</a> section |
| above.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By enabling semi-automatic mode to automatically choose time transitions |
| (option value <code>time</code>), while not automatically choosing the delay durations |
| of time transitions (option value <code>timedur</code>), time transitions are |
| automatically chosen, but the user is still asked to choose the duration of the |
| time transitions. For this choice, all non-time choices are disabled, making |
| only the time related choices available. The effect of the |
| <b class="menuref">time delay</b> |
| button remains the same, i.e. choosing the maximum |
| allowed or available delay. The popup menu for the time delay also still shows |
| the default options, to choose either a specific custom delay duration, or the |
| maximum duration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By enabling semi-automatic mode to automatically choose the delay durations of |
| time transitions (option value <code>timedur</code>), while not automatically choosing |
| the time transition themselves (option value <code>time</code>), the effect of the |
| <b class="menuref">time delay</b> |
| button changes from choosing the time transition with |
| the maximum allowed or available delay, to choosing the time transition and |
| letting the <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a> |
| choose the actual delay duration, based on its own configuration. The popup |
| menu for the time delay then only shows one option, to let the automatic input |
| component choose, identical to the effect of the |
| <b class="menuref">time delay</b> |
| button.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-termination">Termination</h7> |
| <div class="paragraph"> |
| <p>By closing the GUI of the interactive GUI input component, no more interactive |
| choices can be made. The next time an interactive choice is to be made, |
| simulation <a href="#tools-cifsim-chapter-termination">terminates</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>While an interactive choice is to be made via the GUI, the red stop button of |
| the Eclipse console does not function. Once a choice is made, simulation will |
| <a href="#tools-cifsim-chapter-termination">terminate</a>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-automatic">Automatic input mode</h6> |
| <div class="paragraph"> |
| <p> |
| |
| In the automatic input mode, the simulator automatically chooses transitions |
| as well time transition durations. How the simulator chooses however, can be |
| influenced using options. These options are explained below. The final section |
| of this page explains the |
| <a href="#tools-cifsim-input-automatic-limitations">limitations</a> of using these |
| options.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-automatic-trans">Automatic mode choice algorithm option</h7> |
| <div class="paragraph"> |
| <p>In the automatic input mode, the simulator automatically chooses the |
| transitions to take, without any user interaction. The choice that is made |
| can however be influenced using the |
| <b class="menuref">Automatic mode choice algorithm</b> |
| option (<b class="menuref">Input</b> |
| category). The following choices are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>First transition.</p> |
| </li> |
| <li> |
| <p>Last transition.</p> |
| </li> |
| <li> |
| <p>Random transition (random seed).</p> |
| </li> |
| <li> |
| <p>Random transition (specific seed).</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The options to choose the first or last transition do exactly what they state, |
| i.e. they choose the first respectively the last transition from the list of |
| possible transitions. Note that event transitions are always listed before |
| time transitions, but event transitions can only be listed together with time |
| transitions if <a href="#tools-cifsim-chapter-env-events">environment events</a> are |
| present. Also note that if transitions for the <code>tau</code> event are present, they |
| are listed after the transitions for all other events.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The other two options randomly choose a transition from the possible |
| transitions. If a random seed (for the random number generator) is used, each |
| simulation will potentially choose a different trace. In this case, the seed |
| that is used, is <a href="#tools-cifsim-output-chapter-normal">printed</a> to the console |
| at the start of the simulation. If a specific seed is used, then the choices |
| are still random, but can be reproduced. Each simulation, using random |
| automatic input mode, with the same seed, for the same specification, should |
| lead to the same <a href="#tools-cifsim-chapter-traces">trace</a>. Seeds are integer |
| numbers from the range [0 .. 2<sup>30</sup>].</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-automatic-time">Automatic mode time transition duration option</h7> |
| <div class="paragraph"> |
| <p>In the automatic input mode, the simulator automatically chooses the durations |
| of the time transitions, without any user interaction. The choice that is made |
| can however be influenced using the |
| <b class="menuref">Automatic mode time transition duration</b> |
| option (<b class="menuref">Input</b> |
| category). The following choices are |
| available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Maximum allowed duration.</p> |
| </li> |
| <li> |
| <p>Random duration (random seed).</p> |
| </li> |
| <li> |
| <p>Random duration (specific seed).</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The option to choose the maximum allowed duration does exactly what it states, |
| i.e. it chooses the maximum allowed duration for each time transition, until |
| the next potential state event.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The other two options randomly choose a duration for the time transitions. |
| For both options, a uniform random distribution is used, which is sampled to |
| obtain the time at which time transitions are to be 'interrupted' or 'cut off'. |
| The upper bound (exclusive) of the uniform random distribution is to be |
| provided by the user. You can think of these random options as adding an extra |
| automaton to the specification, that could look as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton auto_time_trans_duration: |
| const real UPPER = ...; |
| disc dist real d = uniform(0.0, UPPER); |
| disc real timeToWait; |
| cont t der 1.0; |
| |
| location sampling: |
| initial; |
| edge do (timeToWait, d) := sample d goto waiting; |
| |
| location waiting: |
| edge when t >= timeToWait do t := 0.0 goto sampling; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The upper bound of the uniform real distribution (<code>UPPER</code> > 0), is provided |
| by the user. A sample is taken from the distribution, indicating the time to |
| wait before the time transition is to be interrupted. Once that much time has |
| elapsed, a new sample is taken, and the process repeats itself. The actual |
| implementation is slightly different, in that no actual automaton is added, |
| no additional <code>tau</code> transitions result from using this option, and no zero |
| length time transitions are chosen. However, the effect is very similar.</p> |
| </div> |
| <div class="paragraph"> |
| <p>So, say the user wants to use a uniform distribution over interval [0 .. 10). |
| The simulator takes a sample, say 3.0. Assume we then get a time transition for |
| at most 0.5 time units. We take that entire transition and are left with 2.5 |
| remaining time units (3.0 - 0.5). If we then get another time transition for at |
| most 1.2 time units, we take that one entirely as well. We are left with 1.3 |
| (2.5 - 1.2) time units. If we would then get a time transition for at most 5.0 |
| time units, the automatic input component ensures that we instead get a time |
| transition for at most 1.3 time units, instead of one for at most 5.0 time |
| units. Since we choose to interrupt after 1.3 time units anyway, there is no |
| reason to compute the remainder of the time transition after those 1.3 time |
| units. We choose the entire time transition of 1.3 time units, and compute a |
| new sample. The simulator then once again calculates new transitions, and the |
| process repeats. The next time transition that is calculated will be for the |
| remaining 3.7 (5.0 - 1.3) time units, unless it is interrupted again before |
| that time, i.e. if the new sample is smaller than 3.7.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a random seed (for the random number generator) is used, each simulation |
| will potentially choose a different trace. In this case, the seed that is used, |
| is <a href="#tools-cifsim-output-chapter-normal">printed</a> to the console at the start of |
| the simulation. If a specific seed is used, then the choices are still random, |
| but can be reproduced. Each simulation, using random automatic time transition |
| duration, with the same seed, for the same specification, should lead to the |
| same <a href="#tools-cifsim-chapter-traces">trace</a>. Seeds are integer numbers from the |
| range [0 .. 2<sup>30</sup>].</p> |
| </div> |
| <div class="paragraph"> |
| <p>The random durations are particularly useful in combination with |
| <a href="#tools-cifsim-chapter-env-events">environment events</a>, as it allows the |
| environment events to be chosen at the time the time transition is interrupted. |
| That is, it allows the environment events to occur at random times. |
| Using this option, the user can specify the distribution used for 'cutting up' |
| the time transitions, and thus the possible moments when environment events can |
| potentially take place. This is in addition to the state events, at which the |
| environment events can also be chosen. These new additional possibilities |
| however, are not influenced by the occurrence rate of the events of the system, |
| and allow more control for the user. In particular for cases where the |
| simulation allows infinite time transitions (no state events), the infinite |
| time transitions can then be interrupted to allow environment events to take |
| place.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-automatic-limitations">Limitations</h7> |
| <div class="paragraph"> |
| <p>Using the two options described above, and choosing random for each of them, |
| introduces a certain degree of randomness to the |
| <a href="#tools-cifsim-chapter-traces">trace</a> that the simulator will explore. This |
| randomness however, is rather limited. For one, the distributions that are |
| used are mostly fixed, as the options don’t allow using for instance an |
| exponential distribution. Furthermore, there is no way to specify the |
| distribution for events individually, and it is not possible to specify the |
| distribution between event transitions and time transitions. Concretely, the |
| options for instance don’t enforce that environment events get chosen. They |
| <em>may</em> be chosen when the time transitions are interrupted, or at state events, |
| but that is not guaranteed, as the simulator may choose the time transition |
| again, after the interruption.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The options provide a lightweight, quick, and easy to use approach to adding |
| some randomness. If more control is needed, the environment can instead be |
| modeled explicitly in the CIF model, thus defining when the environment events |
| may or will occur. One way to accomplish this, is by adding a use case.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-undoreset">Undo/reset</h7> |
| <div class="paragraph"> |
| <p>The automatic input mode does not support |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> and |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-trace">Trace input mode</h6> |
| <div class="paragraph"> |
| <p> |
| |
| In the trace input mode, the simulator automatically chooses transitions as |
| well as time transition durations, based on a user provided trace file.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-trace-file">Trace file</h7> |
| <div class="paragraph"> |
| <p>If the trace input mode is used, the |
| <b class="menuref">Trace input file</b> |
| option |
| (<b class="menuref">Input</b> |
| category) can be used to specify the path to the trace file. |
| If the path is not explicitly specified, the input CIF file path is used, where |
| the <code>.cif</code> file extension is removed if present, and a <code>.trace</code> file |
| extension is added.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The trace file uses a line based file format. Leading (at the beginning of the |
| line) and trailing (at the end of the line) whitespace is ignored. Empty lines |
| as well as lines starting with a hash character (<code>#</code>) are ignored as well. |
| Lines starting with a hash character can be used as comment lines. All other |
| lines contain commands.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are two types of commands: option commands and non-option commands. The |
| option commands must always be before the non-option commands.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-option-commands">Option commands</h7> |
| <div class="paragraph"> |
| <p>All option commands use the <code>option NAME VALUE</code> syntax, where <code>NAME</code> is the |
| name of the option, and <code>VALUE</code> is the value of the option. Option commands |
| must be specified in the trace file, before any other (non-option) commands. |
| The remainder of this section explains the available options.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>option strict on/off</em> (default <code>off</code>)</p> |
| <div class="paragraph"> |
| <p>The strict option can be used to specify whether a strict match is |
| expected for an event. If strict mode is on (option strict on), it is |
| considered an error if more than one transition is possible for an event from |
| the trace. If strict mode is off (option strict off), and there are |
| multiple possible transitions for an event from the trace, the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a> is asked to |
| choose between those possible transitions for that single event, based on its |
| own configuration. The strict option applies only to events, not time delays.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>option time off/implicit/explicit</em> (default <code>implicit</code>)</p> |
| <div class="paragraph"> |
| <p>The time option can be used to specify the time mode to use. |
| If the time mode is off (option time off) , time passage is not |
| allowed. That is, time delays/transitions are never chosen, and the value of |
| variable time remains zero during the entire simulation. For this mode, |
| the time command is not allowed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the time mode is implicit (option time implicit), time delays are |
| chosen if necessary. The simulator will use the least amount of time passage |
| possible, to still enable the events as specified in the trace. In other |
| words, if an event is possible no time delays occur, and otherwise the |
| simulator delays for as long as is needed until the event becomes enabled. |
| For this mode, the time command is not allowed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the time mode is explicit (option time explicit), time delays are |
| only possible if the time command explicitly allows time passage.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-transition-commands">Transition commands</h7> |
| <div class="paragraph"> |
| <p>The transition commands can be used to specify the actual trace itself, to |
| choose specific transitions. The following commands are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>event NAME</em></p> |
| <div class="paragraph"> |
| <p>The event command indicates that an event transition should be taken. The |
| event to choose is indicated by the <code>NAME</code> part, which must be an absolute |
| name of an event. For an automaton <code>a</code> with an event <code>e</code>, <code>NAME</code> must |
| be <code>a.e</code>, and the full command would thus be event <code>a.e</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If CIF textual syntax keyword are used as names for events (such as |
| <code>plant</code>), then they must be escaped in <code>.cif</code> files (e.g. <code>$plant</code>). |
| For event commands however, no escape characters (<code>$</code>) should be used |
| in event names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the specified event is not enabled in the current state, the simulator |
| checks whether time passage is allowed and possible. For the off time |
| mode, time passage is not allowed, and the simulation results in deadlock. |
| For the implicit time mode, the simulator delays if a time transition is |
| possible, and otherwise simulation results in deadlock. For the explicit |
| time mode, if the current event command was preceded by an explicit |
| time command, the simulator delays if a time transition is possible, and |
| otherwise (current command not preceded by time command or no time |
| transition possible) simulation results in deadlock. Upon deadlock, |
| simulation <a href="#tools-cifsim-chapter-termination">ends</a>, and a warning is printed |
| to the console to indicate the event that was not enabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If multiple transitions are possible for the event, due to |
| <a href="#tut-basics-chapter-non-determinism">non-determinism</a>, the strict |
| option (see above) determines if and how the simulator proceeds.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>time</em></p> |
| <div class="paragraph"> |
| <p>The time command explicitly indicates that time is allowed to pass, i.e. |
| the simulator may delay by choosing a time transition. This command is only |
| allowed for the explicit time mode.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The time command does not ensure that time passes. It specifies that time |
| passage is allowed, not that it is required. Specifying the time command |
| multiple times without an intermediate event command has the same effect |
| as specifying the time command only once. That is, it doesn’t matter |
| how many times you allow time passage, once is enough.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The trace input mode does not support |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> and |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a>.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-simulation">Simulation</h7> |
| <div class="paragraph"> |
| <p>The commands from the trace file are processed in the order they occur in the |
| trace file. After all commands have been used to select transitions, and no |
| more commands are available, the simulation |
| <a href="#tools-cifsim-chapter-termination">ends</a>. The simulator indicates the |
| simulation has terminated at the request of the user, as the user did not |
| include any more commands in the trace file.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulation is also terminated if deadlock occurs or the |
| <a href="#tools-cifsim-termination-endtime">user-specified simulation end time</a> |
| is reached, even if more (unprocessed) commands are still available.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-svg-chapter-index">SVG input mode</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| |
| In the SVG input mode, the <a href="#tools-cifsim-output-svgviz-chapter-svg">SVG</a> images |
| that are used for <a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualization</a> |
| can be used to interactively control the simulation. Since the SVG images are |
| reused, using the SVG input mode requires the use of SVG visualization.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The idea is that certain SVG elements are coupled (mapped) to events from the |
| CIF specification. Clicking on those graphical elements then results in the |
| corresponding event being executed by the simulator. This way, the user |
| interface of a system can be modeled graphically, and can be coupled to the |
| specification (during simulation), by means of events. The user interface of |
| the system is thus part of the specification, but is controlled interactively |
| at runtime (during simulation) by the user.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The events that are coupled to visualization elements are called |
| <em>SVG interactive events</em> or <em>SVG input events</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p><em>Topics</em></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-svg-chapter-svgin">CIF/SVG input mappings</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-svg-chapter-simulation">Simulation with SVG input</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-svg-chapter-svgin">CIF/SVG input mappings</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| CIF/SVG input mappings couple <a href="#tools-cifsim-output-svgviz-svg-id">ids</a> |
| of <a href="#tools-cifsim-output-svgviz-chapter-svg">SVG</a> elements to events from the |
| CIF specification. CIF/SVG input mappings are |
| <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a>, similar to |
| <a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a>. If the |
| CIF specification contains input mappings, and SVG input mode is not used, the |
| input mappings are simply ignored.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-single-event-input-mapping">Single event input mapping</h8> |
| <div class="paragraph"> |
| <p>The simplest form of an SVG input mapping maps to a single event. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgin id "button" event machine.button.toggle;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This input mapping maps the SVG element with |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a> <code>button</code> to the |
| <code>machine.button.toggle</code> event from the CIF specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Every input mapping must |
| <a href="#tools-cifsim-output-svgviz-svgout-id">specify the id</a> of an SVG |
| element, and an SVG element with that id must exist in the SVG image. |
| Specifying an input mapping for an SVG element turns that SVG element into an |
| <em>interactive SVG element</em>. Note that |
| <a href="#tools-cifsim-input-svg-simulation-groups">groups</a> may be used as |
| interactive SVG elements as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-if-event-input-mapping"><code>if</code> event input mapping</h8> |
| <div class="paragraph"> |
| <p>Sometimes, the simple <em>single event input mapping</em> is not enough. Consider |
| for instance the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton button: |
| event u_pushed, u_released; |
| |
| location Released: |
| initial; |
| edge u_pushed goto Pushed; |
| |
| location Pushed: |
| edge u_released goto Released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification models a <code>button</code> that is initially released (location |
| <code>Released</code>). When the button is pushed (event <code>u_pushed</code>), the location is |
| updated to <code>Pushed</code>. If we now want to couple a graphical representation of |
| a button to this CIF specification, the event to choose depends on the current |
| location of the <code>button</code> automaton. This can be mapped using an |
| <em>if event input mapping</em>, as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgin id "button" event |
| if button.Released: button.u_pushed |
| elif button.Pushed: button.u_released |
| end;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If the button is released, the <code>u_pushed</code> event is chosen, and if the button |
| is pushed, the <code>u_released</code> event is chosen.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>if</code> event input mappings are essentially an <code>if</code> expressions that |
| result in an event rather than a value. The conditions (such as |
| <code>button.Released</code> are guard expressions that evaluates to a boolean value. |
| The guard expressions may be arbitrary expressions, similar to the use of |
| expressions in output mappings.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a condition holds, the corresponding event is chosen. The entries are |
| processed in the order they are specified: if the first guard (of the <code>if</code>) |
| holds, the first event is chosen, otherwise if the second guard |
| (of an <code>elif</code>) holds, the second event is chosen, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The last part of the <code>if</code> is allowed to be an <code>else</code>, to indicate that |
| if none of the previous guards hold, the event of the <code>else</code> is to be chosen. |
| Using an <code>else</code> entry is optional, but if used, there may only be one such |
| entry, and it must be the last entry of the input mapping.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-uniqueness">Uniqueness</h8> |
| <div class="paragraph"> |
| <p>Similar to output mappings, all input mappings must be unique, per SVG image. |
| That is, no two input mappings for the same SVG image may use the |
| same SVG element id. Note that it is allowed to have an input mapping and an |
| output mapping (or even multiple output mappings) for the same SVG element.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-completeness">Completeness</h8> |
| <div class="paragraph"> |
| <p>Input mappings must be complete. Single event input mappings are always |
| complete, as are <code>if</code> event input mappings with an <code>else</code>. For <code>if</code> |
| event input mappings without an <code>else</code>, at least one of the guards must hold. |
| If none of the guards holds, the mapping results in a runtime error during |
| simulation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-svg-chapter-simulation">Simulation with SVG input</h7> |
| <div class="paragraph"> |
| <p> |
| This page explains the use of the SVG input mode of the CIF simulator at |
| runtime (during simulation).</p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-input-svg-simulation-works">How it works</h8> |
| <div class="paragraph"> |
| <p>During simulation, as long as none of the interactive SVG elements (the SVG |
| elements for which an input mapping exists) are clicked, the corresponding |
| events are never chosen. For the other events (the non-interactive events), a |
| choice is made using the <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a>. |
| The automatic input component makes a choice |
| based on its own settings.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect8"> |
| <h9 id="tools-hovering">Hovering</h9> |
| <div class="paragraph"> |
| <p>When moving over one of the interactive SVG elements of the SVG visualization, |
| using the mouse pointer, the border of the SVG element is highlighted in red. |
| This makes it easier to identify the interactive SVG elements in the |
| <a href="#tools-cifsim-output-svgviz-chapter-viewer">SVG visualizer</a>. When an |
| interactive SVG element is clicked, the color is changed from red to green, for |
| as long as the mouse button is not released.</p> |
| </div> |
| </div> |
| <div class="sect8"> |
| <h9 id="tools-clicking">Clicking</h9> |
| <div class="paragraph"> |
| <p>The mouse click (and <em>not</em> the release) makes that the input component will |
| interrupt any time transition that is currently being taken by the simulator. |
| Then, when asked to choose a next transition, it will apply the input mapping |
| for the interactive SVG element that was clicked. The event that results from |
| the input mapping is then chosen. If the event is not enabled at that time, |
| simulation ends in deadlock. To prevent such deadlocks, you can use a |
| <a href="#tut-data-chapter-monitoring">monitor</a> automaton. If multiple transitions |
| are possible for that event, the choice (between the transitions for that event |
| only) is deferred to the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a>, which makes |
| a choice based on its own settings. Note that multiple transitions are only |
| possible if <a href="#tools-cifsim-chapter-complete-mode">complete mode</a> is enabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect8"> |
| <h9 id="tools-queue">Queue</h9> |
| <div class="paragraph"> |
| <p>The SVG input mode allows interactively choosing certain events by clicking on |
| interactive elements of an SVG image. The SVG input mode is however not |
| officially an interactive input mode.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The image plays the part of the environment. Whenever an interactive element is |
| clicked, the element is added to a queue. If a user quickly clicks the same |
| element multiple times, or quickly clicks different elements, they are all |
| stored in the queue, and the queue can grow. The transition to take is |
| automatically chosen, based on the queue of events. If the queue is empty, the |
| environment (the SVG image and the user) doesn’t allow the interactive events. |
| If the queue is not empty, the environment allows exactly one interactive |
| event, the one at the head of the queue. The model, together with the queue, |
| form a closed model, without further interaction. Each interactive SVG element |
| that is clicked, will be used in the order they were clicked, to choose |
| transitions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG input mode internally acts as an automated input mode, that makes |
| choices about which transitions to take, without further user interaction. |
| Since no further user interaction is possible, |
| <a href="#tools-cifsim-input-history-reset-undo">undo</a> and |
| <a href="#tools-cifsim-input-history-reset-undo">reset</a> are also not supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-input-svg-simulation-debugging">Debugging</h8> |
| <div class="paragraph"> |
| <p>The <a href="#tools-cifsim-output-svgviz-debugging-console">console debugging output</a> for CIF/SVG mappings includes |
| debugging output for SVG input mappings. Input mappings that encounter runtime |
| errors have <a href="#tools-cifsim-output-svgviz-debugging-stacktrace">stack traces</a> similar to those of output |
| mappings.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-input-svg-simulation-responsiveness">Responsiveness</h8> |
| <div class="paragraph"> |
| <p>SVG input is usually combined with <a href="#tools-cifsim-output-chapter-realtime">real-time simulation</a>. |
| Clicking an interactive SVG element results |
| in the application of an input mapping, which results in an event. That event |
| is put in the queue. If a time transition is being taken by the simulator, the |
| simulator will continue to take that time transition until the input component |
| interrupts it. However, an input component can only interrupt a time transition |
| during <a href="#tools-cifsim-output-realtime-frames">intermediate frames</a>. As |
| such, choosing a low <a href="#tools-cifsim-output-realtime-framerate">frame rate</a> |
| (typically less than 10 frames per |
| second) can significantly reduce the responsiveness of the SVG input.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Hovering interactive SVG elements highlights their borders in red. This too |
| becomes less responsive when a low frame rate is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-input-svg-simulation-groups">Interactive groups</h8> |
| <div class="paragraph"> |
| <p>It is possible to make a group of SVG elements (an <code>svg:g</code> element) an |
| interactive element. By doing so, all the elements that are part of the group |
| together become one single interactive element.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One practical example where this is very useful, is for buttons with a text |
| label. In SVG, this requires the use of a rectangle and a text label. To ensure |
| that clicking either one of them results in the same event, group the rectangle |
| and text label together in a group. Then assign an |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a> to the group and use that id in |
| an <a href="#tools-cifsim-input-svg-chapter-svgin">input mapping</a>. During simulation, |
| when hovering over either the rectangle or the text label, both will will be |
| highlighted. Clicking on either of them results in the corresponding input |
| mapping being applied, and the resulting event being chosen by the SVG input |
| component.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, if an SVG image is clicked, the simulator will figure out on which |
| graphical element the user clicked. If that element is itself an interactive |
| SVG element, then the corresponding mapping is applied. If it is not an |
| interactive SVG element, its parent (which may be a group) is checked. If the |
| parent is not an interactive SVG element either, the parent of the parent is |
| checked, etc. If none of the ancestors is an interactive SVG element, clicking |
| the element has no effect on the simulation. Because of this behavior, it is |
| strongly recommended not to make a child (or descendant in general) of an |
| interactive SVG element interactive as well.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-semi-automatic">Semi-automatic mode</h6> |
| <div class="paragraph"> |
| <p> |
| By default, in the interactive <a href="#tools-cifsim-input-chapter-console">console</a> |
| and <a href="#tools-cifsim-input-chapter-gui">GUI</a> input modes, the user is asked |
| to choose, even if for instance there is only one possible transition. Having |
| to choose for every transition can become tiresome. To reduce the number of |
| situations where input is required, the semi-automatic mode is available. |
| Semi-automatic mode allows the simulator to automatically choose certain |
| transitions, while leaving the remaining choices for the user. The following |
| choices can be automatically made by the simulator, in semi-automatic mode:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Automatically choose a transition if there is only one transition possible.</p> |
| </li> |
| <li> |
| <p>Automatically choose time transitions, regardless of how many transitions |
| are possible.</p> |
| </li> |
| <li> |
| <p>Automatically choose the delay duration of time transitions.</p> |
| </li> |
| <li> |
| <p>Automatically choose event transitions (for certain events), regardless of |
| how many transitions are possible.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Each of these possible automatic choices can be individually enabled, |
| through the |
| <b class="menuref">Interactive mode automatic transition choice</b> |
| option |
| (<b class="menuref">Input</b> |
| category). As value for the option, comma separated |
| <em>filters</em> should be supplied. The following filters are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>1</code> to automatically choose a transition if there is only one transition |
| possible.</p> |
| </li> |
| <li> |
| <p><code>time</code> to automatically choose time transitions.</p> |
| </li> |
| <li> |
| <p><code>timedur</code> to automatically choose the delay duration of time transitions.</p> |
| </li> |
| <li> |
| <p>The name of an event, to automatically choose event transitions for that |
| event.</p> |
| </li> |
| <li> |
| <p><code>urgent</code> to automatically choose event transitions for all |
| <a href="#tools-cifsim-chapter-env-events">urgent</a> (non-environment) events.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For events, the absolute names of the events are used. That is, for an |
| automaton <code>a</code>, with an event <code>e</code>, the absolute name of the event is |
| <code>a.e</code>. If CIF textual syntax keyword are used as names for events (such as |
| <code>plant</code>), then they must be escaped in <code>.cif</code> files (<code>$plant</code>). For |
| filters however, all escape characters (<code>$</code>) in event names are ignored. |
| The <code>*</code> character can be used as wildcard, to indicate zero or more |
| characters. The special <code>urgent</code> event filter matches all |
| <a href="#tools-cifsim-chapter-env-events">urgent</a> events of the specification. If an |
| event filter doesn’t match any of the events of the CIF model, a warning is |
| printed to the console. If a filter doesn’t have any effect, because a previous |
| filter already turned ensured that the matching events into are automatically |
| chosen, a warning is printed as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>1, g*, t*</code> consist of three filters: <code>1</code>, |
| <code>g*</code>, and <code>t*</code>. The first filter indicates that the simulator should |
| automatically choose a transition if there is only one transition possible. The |
| second and third filters indicate that the simulator should also automatically |
| choose all events starting with an <code>g</code> or a <code>t</code>, such as <code>g</code>, <code>g1</code>, |
| <code>go</code>, etc. Note that the wildcards apply only to events, so <code>t*</code> does not |
| mean that time transitions should be automatically chosen. The <code>t*</code> filter |
| always matches the <code>tau</code> event, as that event is implicitly always present.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If an automatic choice can be made, given the filter and the possible |
| transitions, the transitions are filtered to only keep the ones that can be |
| chosen automatically, and they are sent to the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input component</a>, which then makes the actual choice, |
| depending on its own configuration. Similarly, if the delay duration of a time |
| transition is to be automatically chosen, the automatic input component is |
| asked to choose, based on its own configuration.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-input-chapter-history">State history</h6> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF simulator can be used to explore the |
| <a href="#tools-cifsim-traces-state-space">state space</a> of a CIF model. It is |
| possible to see step by step, what is possible, and choose some transitions. |
| Sometimes, after exploring a bit, you may want to go back a bit, to explore |
| some alternative behavior. Obviously, you can terminate the simulation, and |
| start a new one. There are several downsides to this. First, you have to start |
| from the initial state again, while you may want to only go back a few states, |
| and continue from there. Second, restarting the simulator may take some time, |
| especially for large models. Third, if you use several visualizations, you may |
| have to layout them again, to be able to see all of them.</p> |
| </div> |
| <div id="tools-cifsim-input-history-reset-undo" class="paragraph"> |
| <p>To make it easier to explore alternatives, the simulator supports resetting the |
| simulation to the initial state, as well as undoing a certain number of |
| transitions. This page explains that functionality in more detail.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-history-enable">Enabling history</h7> |
| <div class="paragraph"> |
| <p>The <em>History</em> option (<em>Input</em> category) can be used to enable or disable |
| history. By default history is enabled. Using the option, it can be disabled. |
| Disabling history disables both the reset and the undo functionality, which |
| ensures no time or memory is consumed in keeping track of earlier states.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If history is enabled, it only has an effect if an interactive input mode is |
| used. Other (automatic) input modes will never perform a reset or undo. That |
| is, the simulator will not keep track of any history states, unless an |
| interactive (either fully interactive or |
| <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a>) input mode is |
| used, and history is enabled via the <em>History</em> option.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-state-stack">State stack</h7> |
| <div class="paragraph"> |
| <p>In order for the simulator to be able to go back to earlier states, it will |
| need to remember those states. To that end, the simulator can store states that |
| it has encountered in a state stack. The initial state is remembered |
| separately. So, initially, the following is remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_0.png" alt="history 0"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, state <code>0</code> is the initial state. After two transitions are taken, the |
| following is remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_012.png" alt="history 012"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, two more states, numbered <code>1</code> and <code>2</code> are remembered. After one more |
| transitions is taken, the following is remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_0123.png" alt="history 0123"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, one more state, numbered <code>3</code>, is remembered. In each case, the last |
| shown state is the current state. If we undo two transitions, the following is |
| remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_01.png" alt="history 01"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As two transitions are undone, their resulting states (the last two states) are |
| forgotten. If we take one more transition after the undo, we get the following:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_012.png" alt="history 012"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This state <code>2</code> may be the same one as before, or it may be a new one, if a |
| different simulation choice was made. If we reset the simulation, we forget all |
| but the initial state, and end with up:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_0.png" alt="history 0"> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-input-history-size">Stack size</h7> |
| <div class="paragraph"> |
| <p>For long simulations, a lot of states will need to be remembered. Each state |
| that needs to be remembered costs some amount of memory. To limit the amount |
| of states that are remembered, the <em>History size</em> option (<em>Input</em> category) |
| can be used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If set to infinite, there is no limit to the amount of states that can be |
| remembered. If set to a finite (non-negative) number, at most the given number |
| of states are remembered, apart from the initial state. So, if set to zero, |
| only the initial state is remembered. If set to one, one additional state is |
| remembered, etc. The default history size is <code>100</code> states. Since if set to |
| zero, only the initial state is remembered, this completely disables undo |
| functionality.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By introducing a maximum number of states that can be remembered, this also |
| introduces a maximum number of transitions that can be undone. Let’s consider a |
| history size of <code>3</code>. After three transitions, the following is remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_0123.png" alt="history 0123"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>State <code>3</code> is the current state. It is possible to undo one, two, or three |
| transitions, going back to states <code>2</code>, <code>1</code>, and <code>0</code>, respectively. Now |
| consider what happens when we take another transition. We already remember |
| three states besides the initial state, and have thus reached the maximum |
| number of states to remember. By remembering the new target state of the fourth |
| transition, we need to let go of state <code>1</code>, as it is the oldest remembered |
| state, not taking into account the initial state. After this fourth transition, |
| the following is remembered:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/input/history_0234.png" alt="history 0234"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>State <code>4</code> is the current state. We can undo one transition, to go back to |
| state <code>3</code>. We can also undo two transitions, to go back to state <code>2</code>. |
| However, as we forgot all about state <code>1</code>, we can’t undo three transitions. |
| Due to the <em>gap</em> between states <code>0</code> and <code>2</code>, we can’t undo past state |
| <code>2</code>. As you can see from this example, for a history size of 3, we can undo |
| at most 3 transitions when there is no gap, and at most 2 transitions when |
| there is a gap.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-availability">Availability</h7> |
| <div class="paragraph"> |
| <p>If history is disabled, reset is not available. If history is enabled, reset |
| is available only if the current state is not the initial state. That is, reset |
| is enabled for every state, except for the initial state.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If history is disabled, or the history size is zero, undo is not available. If |
| history is enabled, and the history size is positive or infinite, undo is |
| available. The number of transitions that can be undone depends on the number |
| of states that is remembered. If <code>n</code> states are currently remembered, |
| excluding the initial state, then <code>n - 1</code> transitions can be undone, at the |
| least. If there is no gap, and the current state is not the initial state, then |
| <code>n</code> transitions can be undone.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-requests">Requests</h7> |
| <div class="paragraph"> |
| <p>Reset and undo are only supported by interactive input modes, as explained |
| above.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When the simulator interactively asks the user to choose between some possible |
| transitions, it may also provide the possibility to reset the simulation to |
| the initial state, or to undo some transitions. The details on how the |
| different choices are presented, and how the choice can be made, are explained |
| in the documentation for each of the interactive input modes.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If no transitions are possible, for instance due to |
| <a href="#lang-tut-time-deadlock">deadlock</a> or reaching the |
| <a href="#tools-cifsim-termination-endtime">end-user provided simulation end time</a>, |
| the simulator may interactively ask the |
| user to choose between termination of the simulation, resetting the simulation |
| to the initial state, or undoing some transitions. This choice is only |
| presented if either reset or undo is enabled, as otherwise there is no choice |
| to make. The details on how the different choices are presented, and how the |
| choice can be made, are explained in the documentation for each of the |
| interactive input modes.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-semi-automatic-mode-2">Semi-automatic mode</h7> |
| <div class="paragraph"> |
| <p>By using <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a> mode, a |
| purely interactive input mode, can be made semi-automatic. This can lead to |
| unexpected results, in combination with reset and undo.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider a situation where four transitions have been taken. The first |
| transition was manually chosen, as was the third. The second and fourth |
| transition were automatically chosen. The user is asked to interactively choose |
| the fifth transition. Consider what happens if the user chooses to undo three |
| transitions. The simulator goes back to the state reached after the first |
| transition. The possible transitions are the same as the first time they were |
| calculated. An automatic choice was made for the second transition, so one will |
| also be made the second time around. So, after the second transition is once |
| again automatically chosen, the user is interactively asked to choose the third |
| transition. So, instead of undoing three transitions and getting a choice for |
| the second transition, three transitions are undone, a second transition is |
| automatically chosen, and the user is asked to choose for the third transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Similarly, undoing the fourth transition, will result in a fourth transition |
| being automatically chosen again. If the same choice is made as before, undoing |
| the fourth transition has no effect.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Resetting the simulation to the initial state, will not lead to the user being |
| able to choose the transition to take from the initial state, if the first |
| transition is automatically chosen.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-env-events">Environment events</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| By default, the CIF simulator treats all events are urgent. That is, whenever |
| a transition is possible for any event, time may not progress. In other words, |
| events take priority over time passage. However, not all events should be |
| urgent. As such, the simulator has an |
| <b class="menuref">Environment events</b> |
| option |
| (<b class="menuref">Input</b> |
| category), that makes it possible to let the simulator know |
| about the <em>environment events</em> (non-urgent events). An example of an |
| environment event (non-urgent event) is a button that can be pushed. The button |
| can always be pushed, now or in the future. The corresponding event is thus |
| always enabled, but time should still be able to progress, as the event may |
| not actually happen at this time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As value for the |
| <b class="menuref">Environment events</b> |
| option, comma separated |
| <em>filters</em> should be supplied. Each filter specifies one or more environment |
| events. The absolute names of the events are used. That is, for an automaton |
| <code>a</code>, with an event <code>e</code>, the absolute name of the event is <code>a.e</code>. If CIF |
| textual syntax keyword are used as names for events (such as <code>plant</code>), |
| then they must be escaped in <code>.cif</code> files (<code>$plant</code>). For filters however, |
| all escape characters (<code>$</code>) in event names are ignored. The <code>*</code> character |
| can be used as wildcard, to indicate zero or more characters. The special |
| <code>svg</code> filter can be used to turn all |
| <a href="#tools-cifsim-input-svg-chapter-index">SVG interactive/input events</a> into |
| environment (non-urgent) events. If a filter doesn’t match any of the events of |
| the CIF model, a warning is printed to the console. If a filter doesn’t have |
| any effect, because a previous filter already turned the matching events into |
| environment events, a warning is printed as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>e, a.e, f*, t*</code> consists of four filters: <code>e</code>, |
| <code>a.e</code>, <code>f*</code>, and <code>t*</code>. The first filter indicates that event <code>e</code> is an |
| environment event. The second filter indicates that event <code>e</code> in automaton |
| <code>a</code> is an environment event. The third filter indicates that all events |
| whose absolute name starts with an <code>f</code> are environment events. This could |
| include events <code>f</code>, <code>f1</code>, <code>foo</code>, <code>f.e</code>, etc. The fourth filter is |
| similar to the third filter, but uses character <code>t</code> as a prefix, rather than |
| character <code>f</code>. The <code>t*</code> filter always matches the <code>tau</code> event, as that |
| event is implicitly always present.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-input-modes">Input modes</h6> |
| <div class="paragraph"> |
| <p>By default, the simulator does not know which events of the model are |
| environment events (non-urgent events). By letting the simulator know about |
| them, it can properly simulate them with non-urgent semantics. The CIF |
| simulator however, has several <a href="#tools-cifsim-input-chapter-index">input modes</a>. |
| This section discusses for each input mode, the influence of environment |
| events, and their practical use.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-console">Interactive console input mode</a></p> |
| <div class="paragraph"> |
| <p>When using the interactive console input mode, the simulator will |
| interactively ask the user to choose transitions, from the list of possible |
| transitions printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If however the CIF model contains events that are always enabled (such as a |
| button that can always be pushed), time may never progress. The simulator |
| treats all events as urgent. By specifying the always enabled events as |
| environment events, those events become non-urgent, and the user is free to |
| choose between those environment events and time passage (time transitions). |
| If combined with the <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic mode</a> |
| for the urgent events, the user can |
| choose the environment events and time transitions, while the other/urgent |
| events are automatically chosen by the simulator, reducing the number of |
| choices the user has to make.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-gui">Interactive GUI input mode</a></p> |
| <div class="paragraph"> |
| <p>When using the interactive GUI input mode, the simulator will interactively |
| ask the user to choose transitions, using a GUI (Graphical User Interface).</p> |
| </div> |
| <div class="paragraph"> |
| <p>If however the CIF model contains events that are always enabled (such as a |
| button that can always be pushed), time may never progress. The simulator |
| treats all events as urgent. By specifying the always enabled events as |
| environment events, those events become non-urgent, and the user is free to |
| choose between those environment events and time passage (time transitions). |
| If combined with the <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic mode</a> |
| for the urgent events, the user can |
| choose the environment events and time transitions, while the other/urgent |
| events are automatically chosen by the simulator, reducing the number of |
| choices the user has to make.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-automatic">Automatic input mode</a></p> |
| <div class="paragraph"> |
| <p>When using the automatic input mode, the simulator will automatically choose |
| transitions, based on certain criteria. If the CIF model contains a use case, |
| the simulator automatically simulates that use case.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If however the CIF model contains events that are always enabled (such as a |
| button that can always be pushed), time may never progress. The simulator |
| treats all events as urgent. By specifying the always enabled events as |
| environment events, those events become non-urgent, and the simulator is |
| free to choose between those environment events and time passage (time |
| transitions). If combined with the <em>random</em> |
| <a href="#tools-cifsim-input-automatic-trans">automatic mode choice algorithm</a>, |
| and <em>random</em> |
| <a href="#tools-cifsim-input-automatic-time">automatic mode time transition duration</a>, |
| this allows for the automatic validation of arbitrary traces.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-svg-chapter-index">SVG input mode</a></p> |
| <div class="paragraph"> |
| <p>When using the SVG input mode, the simulator will automatically choose |
| transitions, based on certain criteria. The environment events are usually |
| coupled to the SVG image (using <a href="#tools-cifsim-input-svg-chapter-svgin">CIF/SVG input mappings</a>). |
| This ensures that the environment |
| events are only enabled when the corresponding interactive element of the |
| image is clicked by the user. The SVG image plays the role of the |
| environment, closing the system. If the SVG image only partially closes the |
| system, the remaining environment events can be specified, similar to the |
| way they are specified for the automatic input mode.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supervisory-control-application-domain">Supervisory control application domain</h6> |
| <div class="paragraph"> |
| <p>This section discusses environment events in the application domain of |
| supervisory control, where the system consists of a plant (the hardware), |
| and a supervisor (or other controller that restricts the plant behavior).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Informally, we can distinguish the following types of events:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Controller events</em></p> |
| <div class="paragraph"> |
| <p>Controller events are those events that are initiated by a controller, such |
| as a supervisor. These events are usually controllable events. However, if |
| supervisor synthesis is not used, the events need not necessarily be |
| controllable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For controller events, the behavior is usually fully specified in the CIF |
| model. That is, if the CIF model contains both the plant and the controller, |
| the CIF model determines when the events are enabled, and when they are |
| disabled. The controller events should happen as soon as they are enabled. |
| That is, once the controller determines that for instance a motor should be |
| turned on, the motor should be turned on without further delays. Thus, |
| controller events are urgent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For low-level controllers, the events generally correspond directly to the |
| events of the actuators. For instance, a controller may turn a lamp on or |
| off. For higher level controllers however, there usually is no such direct |
| relation. Furthermore, internal events of the controller (usually event |
| <code>tau</code>, or other events that are neither controllable nor uncontrollable), |
| are considered controller events as well.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Plant events</em></p> |
| <div class="paragraph"> |
| <p>Plant events are those events that are initiated by the plants. These events |
| are usually uncontrollable events. However, if supervisor synthesis is not |
| used, the events need not necessarily be uncontrollable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For plant events, the behavior is usually fully specified in the CIF model. |
| The CIF model models exactly when the events become enabled. For instance, |
| when an elevator moves and reaches its top position, the event that indicates |
| that 'the top position sensor goes on' becomes enabled, and should be |
| executed at that time. That is, the plant model models/follows the physical |
| behavior, and determines when the plants events are enabled. This behavior |
| is fully specified and known, and further delays are undesirable. As such, |
| plant events are urgent.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For low-level plants, the events generally correspond directly to the events |
| of sensors. Typical examples include limit sensors, such as the elevator top |
| position sensor described above, and sensors that detect products throughout |
| the system. For higher level plants however, there usually is no such |
| direct relation. Furthermore, internal events of the plants (usually event |
| <code>tau</code>, or other events that are neither controllable nor uncontrollable), |
| may be considered plant events as well.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Environment events</em></p> |
| <div class="paragraph"> |
| <p>Environment events are those events that are initiated by the environment |
| (anything outside and the plants and the controller). These events are |
| usually uncontrollable events. However, if supervisor synthesis is not used, |
| the events need not necessarily be uncontrollable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF model only observes or monitors the environment events. The |
| environment (outside of the behavior specified in the CIF model), determines |
| when, if ever, the events actually happen, and thus defines their behavior. |
| From the point of view of the CIF model, the environment events can happen at |
| any time, and as such the CIF model allows them at all times. The |
| behavior is left completely unrestricted/free in the CIF specification, as |
| it is unknown when the events will actually happen. Since time may pass |
| before these events actually happen (as determined by the environment, rather |
| than the CIF model), these events are thus non-urgent (from the point of view |
| of the CIF model). If the CIF model would instead consider them to be urgent, |
| the model would always forbid time to progress, even if the environment does |
| not currently allow any environment event to occur, leading to deadlock.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For low-level plants, the events generally correspond directly to the events |
| of sensors. For instance, the buttons of a user interface can be pushed and |
| released. Other typical examples of environment events include events for |
| other user interface elements, and events that indicate that a product has |
| entered the system, from the environment of the system. For higher level |
| plants however, there usually is no such direct relation. Furthermore, |
| internal events of the plants (usually event <code>tau</code>, or other events that |
| are neither controllable nor uncontrollable), may be considered plant events |
| as well.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Thus, for plant events as well as for controller events, the CIF model |
| specifies/defines when the events may/should occur, while for environment |
| events the specification always allows them, and lets the environment |
| choose/determine when they actually occur. In other words, plant/controller |
| events originate from within the specification (internal behavior), while |
| environment events originate outside of the specification (external behavior).</p> |
| </div> |
| <div class="paragraph"> |
| <p>A closed system is a system for which the entire behavior is specified in the |
| CIF model. Closed systems have no environment events.</p> |
| </div> |
| <div class="paragraph"> |
| <p>An open system does not model the environment. As such, open systems typically |
| have plant events, controller events, and environment events. The environment |
| events are then unrestricted in the CIF model, leaving the environment (which |
| is not specified) free to determine its own behavior, and thus the behavior |
| (enabledness) of the environment events.</p> |
| </div> |
| <div class="paragraph"> |
| <p>An open system can be closed by adding a use case, which models one possible |
| sequence of behavior of the environment, over time. That is, the added use case |
| eliminates environment events, by defining when they are enabled. Open systems |
| can also be closed by the simulator, as described above for the different |
| input modes.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, consider the following open system:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton Button: |
| uncontrollable u_pushed, u_released; |
| |
| location Released: |
| initial; |
| edge u_pushed goto Pushed; |
| |
| location Pushed: |
| edge u_released goto Released; |
| end |
| |
| plant automaton Lamp: |
| controllable c_on, c_off; |
| |
| location Off: |
| initial; |
| edge c_on goto On; |
| |
| location On: |
| edge c_off goto Off; |
| end |
| |
| supervisor automaton ButtonLampController: |
| location: |
| initial; |
| edge Lamp.c_on when Button.Pushed; |
| edge Lamp.c_off when Button.Released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here we have a simple button and a lamp. The lamp can only be turned on while |
| the button is pushed, and will be turned off as soon as the button is released. |
| The button events are environment events, since it always possible to either |
| push the button, or release it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By specifying the button events as environment events, and specifying the the |
| lamp events as <a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a> |
| events, we can use the <a href="#tools-cifsim-input-chapter-console">interactive console input mode</a> |
| or the <a href="#tools-cifsim-input-chapter-gui">interactive GUI input mode</a> to try different traces, |
| where we only have to |
| choose between the button events and how much time we want to let pass.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Alternatively, we could add a use case, modeling one possible behavior of a |
| user:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton User: |
| cont t der 1.0; |
| |
| location: |
| initial; |
| edge Button.u_pushed, Button.u_released when t >= 1 do t := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specifies that the user either pushes or releases the button, after one |
| unit of time has passed (typically one second). Since clock <code>t</code> is reset each |
| time, the user repeats this behavior. Thus, the button is pushed after one |
| second, for one second, after three seconds, for one second, after five |
| seconds, for one second, etc. This extended model (with use case), can be |
| simulated using the <a href="#tools-cifsim-input-chapter-automatic">automatic input mode</a>, as the |
| <code>User</code> plant automaton closes the system.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-output-chapter-index">Simulation output</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF simulator can produce various forms of output.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-console">Console output</h6> |
| <div id="tools-cifsim-output-mode" class="paragraph"> |
| <p>The default form of output is to the console. The type of console output to |
| produce, is determined by the |
| <b class="menuref">Output mode</b> |
| option |
| (<b class="menuref">General</b> |
| category). The following modes are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Error</em>: produces only error output. It is recommended not to use this mode. |
| Use the warning mode instead, if you wish to limit the amount of console |
| output.</p> |
| </li> |
| <li> |
| <p><em>Warning</em>: produces error and warning output. Use this mode to be informed |
| about potential problems, while keeping the amount of console output to a |
| minimum.</p> |
| </li> |
| <li> |
| <p><em>Normal</em>: produces error, warning, and normal output. This is the default |
| output mode. The information that is printed to the console for normal output |
| can be configured using the <a href="#tools-cifsim-output-chapter-normal">Normal output</a> option.</p> |
| </li> |
| <li> |
| <p><em>Debug</em>: produces error, warning, normal, and debug output. This mode can be |
| used to print additional debugging information to the console. The |
| information that is printed to the console for normal output can be |
| configured using the <a href="#tools-cifsim-output-chapter-debug">Debug output</a> |
| option.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The simulator can thus produce two types of configurable console output:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-normal">Normal console output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-debug">Debug console output</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="tools-cifsim-output-components" class="paragraph"> |
| <p><strong>Output components</strong></p> |
| </div> |
| <div class="paragraph"> |
| <p>Besides console output, the simulator also features a powerful and extensible |
| output framework. This framework allows for the addition of output components, |
| such as visualizers. The following output components are currently available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-index">Print output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualizer</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-trajdata">Trajectory data output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-plotviz">Plot visualizer</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-stateviz">State visualizer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Other topics</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-realtime">Real-time simulation</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-normal">Normal console output</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Normal console output mainly focuses on the state of the specification, and the |
| progress of the simulation.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-normal-types">Available types of normal output</h7> |
| <div class="paragraph"> |
| <p>The following types of normal output are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>The initial state</em> [<code>state-init</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints the initial state to the console.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The target states</em> [<code>state-target</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints all target states to the console. This |
| includes all states reached by event transitions and time transitions. |
| Specifically, it excludes the initial state, and it includes the |
| final/deadlock state.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The final state</em> [<code>state-final</code>]</p> |
| <div class="paragraph"> |
| <p>Prints the final state to the console, regardless of whether or not the final |
| state is a deadlock state.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The deadlock state</em> [<code>state-deadlock</code>]</p> |
| <div class="paragraph"> |
| <p>Prints the final state to the console, but only if it is a deadlock state.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The intermediate states</em> [<code>state-intermediate</code>]</p> |
| <div class="paragraph"> |
| <p>Prints all intermediate states to the console. Intermediate states are the |
| states that are used to generate |
| <a href="#tools-cifsim-output-realtime-frames">intermediate frames</a>, for smooth |
| visualizations. The intermediate states are generated for states between the |
| start and end states of time transitions, when |
| <a href="#tools-cifsim-output-chapter-realtime">real-time</a> simulation is enabled. Note |
| that this does not include the initial state, target states, and |
| final/deadlock states.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The algebraic variables as part of the state</em> [<code>state-alg-vars</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints the algebraic variables (derived state) as part of the state. This |
| applies to all states, including the states for intermediate frames. If no |
| state information is printed, this output type has no effect. Disabling |
| printing of algebraic variables excludes algebraic variables, regardless of |
| whether <a href="#tools-cifsim-output-normal-state-filter">state filtering</a> |
| includes or excludes them.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The derivatives as part of the state</em> [<code>state-derivs</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints the derivatives of the continuous variables (derived state) as part of |
| the state. This applies to all states, including the states for intermediate |
| frames. If no state information is printed, this output type has no effect. |
| The derivative of variable <code>time</code> is not included. Disabling printing of |
| derivatives excludes derivatives, regardless of whether |
| <a href="#tools-cifsim-output-normal-state-filter">state filtering</a> includes |
| or excludes them.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The possible transitions (for interactive console choice only)</em> [<code>trans-minimal</code>]</p> |
| <div class="paragraph"> |
| <p>Prints the possible transitions to the console, if the |
| <a href="#tools-cifsim-input-chapter-console">interactive console input mode</a> is used. Multiple possible |
| transition are always printed. Single possible transitions are only printed |
| if automatic choice for a single possible transition is disabled. Nothing |
| is printed if no transitions are possible.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The possible transitions (for interactive console choice, or if more than one transition)</em> [<code>trans-default</code>]</p> |
| <div class="paragraph"> |
| <p>Similar to 'interactive console choice only', but additionally always prints |
| the possible transitions, if there are multiple possible transitions, |
| regardless of the <a href="#tools-cifsim-input-chapter-index">input mode</a>.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The possible transitions (always)</em> [<code>trans-always</code>]</p> |
| <div class="paragraph"> |
| <p>Always print the possible transitions to the console, regardless of the input |
| mode, and the number of possible transitions. However, nothing is printed if |
| no transitions are possible.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The chosen transitions</em> [<code>chosen-trans</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints the chosen transitions (the transitions that are about to be taken), |
| to the console.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The interrupted transitions</em> [<code>interrupted-trans</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints information about interrupted transitions (time transitions that are |
| stopped prematurely) to the console.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The simulation result</em> [<code>sim-rslt</code>] (default)</p> |
| <div class="paragraph"> |
| <p>Prints the simulation result the console, at the end of the simulation, if |
| simulation did not result in a runtime error.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>The random seeds used for the random generators</em> [<code>seeds</code>] (default)</p> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-normal-seeds" class="paragraph"> |
| <p>Prints the seeds used for the random generators to the console, to allow |
| reproducing the simulation <a href="#tools-cifsim-chapter-traces">trace</a>. Only if a |
| random seed is used, is the seed printed. That is, for user-specified seeds, |
| the seed is not printed. The following seeds may be printed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The seed used for the random <a href="#tools-cifsim-input-automatic-trans">automatic mode choice algorithm</a>.</p> |
| </li> |
| <li> |
| <p>The seed used for the random <a href="#tools-cifsim-input-automatic-time">automatic mode time transition duration</a>.</p> |
| </li> |
| <li> |
| <p>The seed used for the first random generator for a <a href="../distr-seeds.html">stochastic distribution</a>. |
| The seed is only printed if it is used to create a random number generator for at least one stochastic |
| distribution.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p><em>The print declarations output</em> [<code>print</code>] (default)</p> |
| <div id="tools-cifsim-output-normal-print" class="paragraph"> |
| <p>Prints the output generated by <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print declarations</a>.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-normal-output-option">Normal output option</h7> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the different types of output can be enabled and |
| disabled individually (<b class="menuref">Normal output</b> |
| option, |
| <b class="menuref">Output</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>-o</code> or <code>--output</code> option, the names of |
| the different types of normal output, as specified between square brackets, |
| should be used, separated by commas. The output types indicated with |
| '(default)' are enabled when default settings are used, i.e. when the |
| <code>-o</code> or <code>--output</code> option is not used. As an example, consider |
| <code>-o print,seeds</code> or <code>--output=print,seeds</code>. Only output generated by print |
| declarations (due to <code>print</code>) and output about the used seeds for random |
| generators (due to <code>seeds</code>) is enabled, while all other output is disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The output types that are specified using the option replace the default output |
| types. However, it is also possible to specify additions and removals relative |
| to the default output, by prefixing output types with a <code>+</code> or <code>-</code> |
| respectively. For instance, when using <code>-o -print,+trans-always</code> or |
| <code>--output=-print,+trans-always</code> the default output is used, with print |
| declarations output excluded from it (due to <code>-print</code>), and with always |
| printing possible transitions enabled (due to <code>+trans-always</code>). Replacements |
| (no prefix) may not be combined with additions/removals (<code>+</code> or <code>-</code> |
| prefix).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying a replacement output type twice leads to a warning being printed to |
| the console. Adding an output type that is already present or removing an |
| output type that is not present, also leads to a warning being printed.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-output-details">Output details</h7> |
| <div class="paragraph"> |
| <p>When printing states, variable <code>time</code> is always printed first. It is followed |
| by the current location of each of the automata, the current values of the |
| state variables (the discrete and continuous variables), the current values of |
| the derivatives of the continuous variables, and the current values of the |
| algebraic variables. Except for variable <code>time</code>, the state objects are sorted |
| alphabetically based on their absolute names. For automata with a single |
| nameless location, the current location is always <code>*</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For variables with a function type and implicit default values, the |
| default values may include <code>defaultValueFunc</code>, <code>defaultValueFunc2</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When printing the possible transitions, the event transitions are printed |
| first, followed by the <code>tau</code> transitions, and the time transition. The event |
| transitions are sorted alphabetically on the names of the events.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-normal-state-filter">State filtering</h7> |
| <div class="paragraph"> |
| <p>By default, when printing states, all state objects are included. Using |
| the |
| <b class="menuref">Normal output state filters</b> |
| option |
| (<b class="menuref">Output</b> |
| category), the state objects can be filtered. The |
| <b class="menuref">Normal output state filters</b> |
| option only has effect |
| if states are printed at all.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As value for the option, comma separated <em>filters</em> should be supplied. Each |
| filter specifies one or more state objects. The absolute names of the objects |
| are used. That is, for an automaton <code>a</code>, with a variable <code>x</code>, the absolute |
| name of the variable object is <code>a.x</code>. If CIF textual syntax keyword are |
| used as names for events (such as <code>plant</code>), then they must be escaped in |
| <code>.cif</code> files (<code>$plant</code>). For filters however, all escape characters (<code>$</code>) |
| in the names are ignored. The <code>*</code> character can be used as wildcard, to |
| indicate zero or more characters. If a filter doesn’t match any of the state |
| objects of the CIF model, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, filters include matching state objects. Filters may however be |
| preceded by a <code>-</code> character, turning them into exclusion filters, which |
| exclude matching states objects rather than including them. Filters are |
| processed in the order they are specified, allowing for alternating additions |
| and removals. If a filter does not result in the addition/removal of any state |
| objects to/from the filter result, a warning is printed to the console. A |
| warning is also printed if the entire state is filtered out.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>a.*,-a.b*,a.bc*</code> consists of three filters: |
| <code>a.*</code>, <code>-a.b*</code>, and <code>a.bc*</code>. The first filter indicates that state |
| objects whose absolute names start with <code>a.</code> are to be included. The second |
| filter indicates that from those matching state objects, the state objects |
| whose absolute names start with <code>a.b*</code> are to be excluded. To that result, |
| the third filter adds those state objects whose absolute names start with |
| <code>a.bc*</code>. For instance, if a specification contains state objects <code>time</code>, |
| <code>a.a</code>, <code>a.b</code> <code>a.bb</code>, <code>a.bc</code>, <code>a.b.c</code>, <code>a.bc</code>, <code>a.bcc</code>, and |
| <code>a.bcd</code>, the result of the three filters is that the following state objects |
| are displayed: <code>a.a</code>, <code>a.bc</code>, <code>a.bc</code>, <code>a.bcc</code>, and <code>a.bcd</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default option value (filter) is <code>*</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Regardless of whether the filtered result includes them or not, all algebraic |
| variables and derivatives of continuous variables may be excluded, using the |
| <a href="#tools-cifsim-output-normal-types">Normal output option</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-profiling">Profiling</h7> |
| <div class="paragraph"> |
| <p>If <a href="#tools-cifsim-chapter-profiling">profiling</a> is enabled, all normal output is |
| automatically disabled. That is, profiling suppresses all normal output.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-debug">Debug console output</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The following types of debug output are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Debug the CIF/SVG declarations</em> [<code>svg</code>]</p> |
| <div class="paragraph"> |
| <p>Prints debugging information to the console, for the |
| <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a>. For more |
| information on this kind of debugging output, see the page on |
| <a href="#tools-cifsim-output-svgviz-debugging-console">console debugging</a> for |
| CIF/SVG declarations.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Debug the parser</em> [<code>parser</code>]</p> |
| <div class="paragraph"> |
| <p>Prints debugging information to the console, for the parser. This information |
| is primarily intended for the developers of the simulator, and not for end |
| users.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Debug the generated code (by writing it to disk)</em> [<code>gen-code</code>]</p> |
| <div class="paragraph"> |
| <p>The simulator generates highly optimized code for the specification. Enabling |
| this debugging output, writes the generated code to disk, for |
| <a href="#tools-cifsim-chapter-debug-gen-code">further debugging</a>. This information is primarily |
| intended for the developers of the simulator, and not for end users.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Debug the ODE solver</em> [<code>ode</code>]</p> |
| <div class="paragraph"> |
| <p>Prints debugging information to the console, for the |
| <a href="#tools-cifsim-solver-chapter-index">ODE solver</a>. This information can for |
| instance be used to figure out why a state event (guard change) |
| <a href="#tools-cifsim-solver-chapter-root-problems">was missed</a>.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-debug-output-option">Debug output option</h7> |
| <div class="paragraph"> |
| <p>In the option dialog, each of the different types of output can be enabled and |
| disabled individually |
| (<b class="menuref">Debug output</b> |
| option, |
| <b class="menuref">Output</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the command line, using the <code>-d</code> or <code>--debug</code> option, the names of |
| the different types of debug output, as specified between square brackets, |
| should be used, separated by commas. By default, i.e. when not using the |
| <code>-d</code> or <code>--debug</code> option, all debug output is disabled. As an example, |
| consider <code>-d parser,svg</code> or <code>--debug=parser,svg</code>. Debug output is printed |
| for the parser (due to <code>parser</code>) and CIF/SVG declarations (due to <code>svg</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifying an output type twice leads to a warning being printed to the |
| console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Enabling any debug output, automatically changes the <a href="#tools-cifsim-output-chapter-index">output mode</a> |
| to 'debug mode'.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-profiling-2">Profiling</h7> |
| <div class="paragraph"> |
| <p>If <a href="#tools-cifsim-chapter-profiling">profiling</a> is enabled, all debug output is |
| automatically disabled. That is, profiling suppresses all debug output.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-print-chapter-index">Print output</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF simulator supports several forms of |
| <a href="#tools-cifsim-output-chapter-index">output</a>. By default, simulation results, such as the |
| current <a href="#tools-cifsim-traces-state">state</a>, are printed to the console. |
| While this provides useful information, it can also be useful to generate |
| custom output, tailored to ones specific needs. To allow this, the CIF |
| simulator supports <em>print output</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulation using the CIF simulator results in a |
| <a href="#tools-cifsim-traces-traces">trace</a>. A trace consists of the |
| <a href="#tools-cifsim-traces-state">states</a> that are encountered and the |
| transitions that are taken, during the simulation. The print output |
| declarations allow specifying for which transitions text should be printed |
| (for instance only for transitions for a certain event), when the text should |
| be printed (for instance before or after the transition), where the text should |
| be printed (for instance to a file), and what text should be printed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Print output declarations are an extension to the CIF language, and can be |
| specified directly in the CIF specification. They are only used to couple |
| the model to textual output. They don’t influence the behavior of the model |
| itself. The CIF <a href="#tools-chapter-text-editor">text editor</a> provides full |
| integration for the print output declarations extension, complete with syntax |
| highlighting, background validation, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Print output can be used to generate text that after simulation is further |
| processed, for instance for visualization or for analysis using statistical |
| software. Print output can also be useful for debugging,</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-quick-example">Quick example</h7> |
| <div class="paragraph"> |
| <p>This example serves only to give a quick taste of what print output |
| declarations look like:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "out.txt"; |
| |
| print x for e;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This example prints the value of variable <code>x</code> to a file <code>out.txt</code> each |
| time after a transition for event <code>e</code> is taken.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-documentation">Documentation</h7> |
| <div class="paragraph"> |
| <p>The tutorials introduce print declarations and text formatting, they explain |
| the general idea behind them, and they show how to use them, all by means of |
| examples. The tutorials are focused on practical use, and do not cover all uses |
| and other details.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-tut-print">Print output tutorial</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-tut-fmt">Text formatting tutorial</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The reference documentation discusses all details related to text output and |
| text formatting. It is much more technical than the tutorials.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-printdecl">Print declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-printfile">Print file declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-sim">Simulation with print output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-fmt">Text formatting details</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-tut-print">Print output tutorial</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This tutorial explains print output by means of examples. It does not explain |
| all uses of print output, and all details related to print output. For those |
| details, see the reference documentation instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In this tutorial, when printed console output is shown, all output that the |
| simulator can generate other than output for print declarations, is omitted.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Before we start with the examples, the |
| <a href="#tools-cifsim-output-print-tut-print-model-trace">Example model and simulation trace</a> section introduces the |
| example model and simulation trace on which the examples are based. Then, the |
| following examples are explained in detail:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex1">Example 1: Printing the buffer count for all states</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex2">Example 2: Printing to a file</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex3">Example 3: Printing the odd/even status for all states</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex4">Example 4: Printing only for odd states</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex5">Example 5: Printing the result of adding an item</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex6">Example 6: Printing addition/removal results</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex7">Example 7: Printing value changes</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex8">Example 8: Printing headers and footers</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex9">Example 9: Printing the new time after time passes</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex10">Example 10: Printing all unique time values</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-tut-print-ex11">Example 11: Printing transitions to/from a location</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-model-trace">Example model and simulation trace</h8> |
| <div class="paragraph"> |
| <p>The examples of print output in this tutorial all make use of the same CIF |
| model:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton buffer: |
| event add, remove; |
| disc int cnt = 5; |
| |
| location: |
| initial; |
| edge add when cnt < 10 do cnt := cnt + 1; |
| edge remove when cnt > 0 do cnt := cnt - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>buffer</code> initially contains five items (<code>cnt = 5</code>). As long as there |
| is room in the buffer (<code>cnt < 10</code>), an item can be added (event <code>add</code>) to |
| the buffer. As long as the buffer is not empty (<code>cnt > 0</code>), an item can be |
| removed (event <code>remove</code>) from the buffer. During simulation, it is possible |
| to <a href="#tools-cifsim-input-chapter-index">choose</a> between adding an item to the |
| buffer, and removing an item from the buffer. The following is a potential |
| simulation trace:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/print/trace_normal.png" alt="trace normal"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the initial state (S1), variable <code>cnt</code> has value <code>5</code>. An item is then |
| added (transition for the event <code>add</code>), resulting in a new state (S2), where |
| <code>cnt</code> has value <code>6</code>. After that, another item is added, leading to state |
| S3, where <code>cnt</code> has value <code>7</code>. Finally, an item is removed by means of a |
| transition for event <code>remove</code>, leading to state S4, where <code>cnt</code> has value |
| <code>6</code> again.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex1">Example 1: Printing the buffer count for all states</h8> |
| <div class="paragraph"> |
| <p>If we want to print for every state (S1 through S4), the number of items in the |
| buffer, we could add the following print declaration to automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, as a result of this print declaration, the following text is printed to |
| the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">5 |
| 6 |
| 7 |
| 6</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>That is, for every state (S1 through S4), the value of variable <code>cnt</code> is |
| printed, on a new line.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex2">Example 2: Printing to a file</h8> |
| <div class="paragraph"> |
| <p>Consider the following print declarations:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt file "a.txt"; |
| print cnt * 2 file "b.txt";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first print declaration results in the number of items in the buffer being |
| printed for every state of the simulation trace, to a file named <code>a.txt</code>. The |
| second print declaration prints the number of items in the buffer multiplied by |
| two, to a file named <code>b.txt</code>. These declarations use local file declarations |
| to specify the file to which output is to be written. It is also possible to |
| use global print file declarations:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "ab.txt"; |
| print cnt; |
| print cnt * 2;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The print file declaration declares that output of this scope is to be printed |
| to a file named <code>ab.txt</code>. The two print declarations don’t specify a local |
| file declaration, and thus use the default file for their scope, in this case |
| file <code>ab.txt</code>. Alternating lines with the number of items in the buffer and |
| twice that amount are thus printed to that file.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex3">Example 3: Printing the odd/even status for all states</h8> |
| <div class="paragraph"> |
| <p>If we want to print for every state, whether the buffer contains an odd or even |
| number of items, we could add the following print declaration to automaton |
| <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print if cnt mod 2 = 0: "even" else "odd" end;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, as a result of this print declaration, the following text is printed to |
| the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">odd |
| even |
| odd |
| even</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex4">Example 4: Printing only for odd states</h8> |
| <div class="paragraph"> |
| <p>If we want to print the number of items in the buffer, but only for states |
| where the number of items is odd, we could add the following print declaration |
| to automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt when cnt mod 2 = 1;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, as a result of this print declaration, the following text is printed to |
| the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">5 |
| 7</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex5">Example 5: Printing the result of adding an item</h8> |
| <div class="paragraph"> |
| <p>If we want to print the result of adding an item, that is the new buffer count |
| after a transition for the <code>add</code> event, we could add the following print |
| declaration to automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt for add;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, as a result of this print declaration, the following text is printed to |
| the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">6 |
| 7</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Since an item is added to the buffer twice, two lines of text are printed.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex6">Example 6: Printing addition/removal results</h8> |
| <div class="paragraph"> |
| <p>If we want to print the resulting buffer count after every change to the buffer |
| (addition or removal), we could add the following print declaration to |
| automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt for add, remove;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, as a result of this print declaration, the following text is printed to |
| the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">6 |
| 7 |
| 6</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Two items are added to the buffer, and one item is removed from the buffer, |
| leading to three lines of text being printed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since the <code>add</code> and <code>remove</code> events are the only events in the system, and |
| no edges exist without an event (which would implicitly use the <code>tau</code> event), |
| the print declaration can also be specified as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt for event;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>That is, the value of variable <code>cnt</code> is printed after each event transition.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex7">Example 7: Printing value changes</h8> |
| <div class="paragraph"> |
| <p>If we want to print the buffer count before and after removal of an item from |
| the buffer, we could add the following print declaration to automaton |
| <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print pre cnt post cnt for remove;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As a result of this print declaration, the following text is printed to the |
| console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">7 |
| 6</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As only one item is removed for our example trace, two lines of text are |
| printed, one with the buffer count before the removal (due to <code>pre cnt</code>), |
| and one with the buffer count after the removal (due to <code>post cnt</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex8">Example 8: Printing headers and footers</h8> |
| <div class="paragraph"> |
| <p>If we want to print for every state (S1 through S4), the number of items in the |
| buffer, we could add the following print declaration to automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print cnt;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If we want to print some text before this, as a header, and some text after |
| this, as a footer, we could add the following print declaration to the top |
| level scope of the specification, or to automaton <code>buffer</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print "header" for initial; |
| print "footer" for final;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As a result of the original print declaration, and these two new print |
| declarations, the following text is printed to the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">header |
| 5 |
| 6 |
| 7 |
| 6 |
| footer</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex9">Example 9: Printing the new time after time passes</h8> |
| <div class="paragraph"> |
| <p>In the example simulation trace given at the top of this page, no passage of |
| time is included. If however a trace includes time passage, it is possible to |
| filter printing to only time transitions. For instance, if we want to print the |
| new time after time passes, we could use the following print declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print time for time;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This prints the value of variable <code>time</code>, every time after a time transition. |
| The first <code>time</code> in the print declaration denotes that the value of variable |
| <code>time</code> should be printed, and the second <code>time</code> denotes that it should be |
| printed only after passage of time (after time transitions). As an example, |
| the following could be printed to the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">0.005 |
| 0.75 |
| 3.1 |
| 7.9</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex10">Example 10: Printing all unique time values</h8> |
| <div class="paragraph"> |
| <p>In the <a href="#tools-cifsim-output-print-tut-print-ex9">ninth example</a>, we |
| printed the new time value after each time transition. However, initially time |
| is zero. Since the initial state is not reached via a time transition, time |
| zero is not printed. We could adapt the print declaration to the following, to |
| print all unique values of variable <code>time</code>, for all states of the simulation |
| trace:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print time for initial, time;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This initially prints the value of variable <code>time</code>, and also prints it after |
| every time transition. As an example, the following could be printed to the |
| console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">0.0 |
| 0.005 |
| 0.75 |
| 3.1 |
| 7.9</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-tut-print-ex11">Example 11: Printing transitions to/from a location</h8> |
| <div class="paragraph"> |
| <p>In the example model given at the top of this page, automaton <code>buffer</code> has |
| only one location. If however an automaton has multiple locations, it may be |
| useful to print the effect of transitions ending in a certain location, or the |
| state of the system for transitions starting in a certain location. Consider |
| the following print declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print x for event when aut.loc;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This prints the value of variable <code>x</code> after event transitions leading to a |
| state where location <code>loc</code> is the current location of automaton <code>aut</code>. |
| That is, whenever an event transition leads to entering that location, the |
| value of variable <code>x</code> after that transition is printed. Since self loops have |
| the same source and target location, this includes self loops. To exclude self |
| loops, use the following print declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print x for event when pre not aut.loc post aut.loc;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This print declaration prints the same text, but only prints it after event |
| transitions from a state where location <code>loc</code> is not the current location |
| of automaton <code>aut</code> to a state where location <code>loc</code> is the current location |
| of automaton <code>aut</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>So far in this example, we printed text for transitions ending in a location. |
| To print text for transitions starting in a location, consider the following |
| print declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print pre y for event when pre aut.loc post not aut.loc;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This print declaration prints the value of variable <code>y</code> in the state that is |
| exited by the transition, for all event transitions that start in location |
| <code>loc</code> of automaton <code>aut</code>, but do end in that same location.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-tut-fmt">Text formatting tutorial</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This tutorial explains text formatting by means of examples. It does not |
| explain all uses of text formatting, and all details related to text |
| formatting. For those details, see the |
| <a href="#tools-cifsim-output-print-chapter-ref-fmt">Text formatting details</a> page instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In this tutorial, when printed console output is shown, all output that the |
| simulator can generate other than output for print declarations, is omitted.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-introduction">Introduction</h8> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print "Time=" + <string>time;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>When simulated, it could give the following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>Time=0.0 |
| Time=3.333333333333336 |
| Time=5.000000000000001 |
| Time=10.0</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As you can see, due to rounding and simulation imprecision, the length of the |
| textual representations of the values of <code>time</code> can vary wildly during |
| simulation. Furthermore, the explicit casts (conversions) from real to string |
| (<code><string></code>) and string concatenation (the <code>+</code> operator) can quickly |
| become cluttered, and hard to read.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To improve readability of the print declaration, we could adapt the CIF |
| specification to the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("Time=%s", time);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, manual text construction has been replaced by the use of the <code>fmt</code> |
| standard library function. The first argument is a <em>format pattern</em>, and the |
| remaining arguments are the values that are to be included in the text, in |
| this case the value of variable <code>time</code>. The <code>fmt</code> function ensures that we |
| no longer have to use casts. We also no longer have to create pieces of text |
| and concatenate them (using the <code>+</code> operator).</p> |
| </div> |
| <div class="paragraph"> |
| <p>This is a typical use of a format pattern. The print declaration prints the |
| value that results from text formatting. The value that is used is the value of |
| variable <code>time</code>. The value of this variable is not used 'as is', but is |
| instead converted to a textual representation using the format pattern. This |
| format pattern specifies that the resulting text should start with <code>Time=</code>. |
| It also specifies that the value (of variable <code>time</code>) should be included at |
| the end of the textual representation. The <code>%s</code> part of the format pattern is |
| a <em>format specifier</em>. The <code>%s</code> specifier is the generic specifier that can |
| convert any type of value to a textual representation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When simulated, this new specification gives the exact same output as the |
| previous version.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-real-value-formatting">Real value formatting</h8> |
| <div class="paragraph"> |
| <p>As we saw in the previous section, due to rounding and simulation imprecision, |
| the length of the generic textual representations of the values of variable |
| <code>time</code> can vary wildly during simulation. This reduces readability of the |
| results, as a lot of irrelevant digits are included. Consider the following |
| alternative CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("Time=%.2f", time);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, instead of a <code>%s</code> specifier, a <code>%f</code> specifier is used. This specifier |
| can only be used for <code>real</code> numbers, and indicates that the number should be |
| formatted as a floating point number in decimal representation. The <code>.2</code> part |
| specifies the precision, and indicates that the floating point number in |
| decimal notation should have exactly two digits after the decimal point. When |
| simulated, this could give the following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>Time=0.00 |
| Time=3.33 |
| Time=5.00 |
| Time=10.00</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-putting-values-in-columns">Putting values in columns</h8> |
| <div class="paragraph"> |
| <p>In the examples above, we included a single value in the output. Now consider |
| the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%.2f %.2f %.2f", x, y, z);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the values of variables <code>x</code>, <code>y</code>, and <code>z</code> are included in the |
| formatted result. The format pattern includes each of the values (the first |
| <code>%.2f</code> includes the value of variable <code>x</code>, the second <code>%.2f</code> includes the |
| value of variable <code>y</code>, etc). The format pattern includes spaces between the |
| format specifiers (between the <code>%.2f</code> parts), and thus the formatted values |
| include spaces between them as well. When simulated, this could give the |
| following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>1.50 0.00 -3.57 |
| 2.34 3.75 5.78 |
| 4.71 12345.34 -3.12 |
| -3.25 1.25 99.20</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Due to some larger values being mixed with shorter values, as well as due to |
| having both positive and negative values, the output is not so easy to read. |
| This can be solved by using the following CIF specification instead:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%10.2f %10.2f %10.2f", x, y, z);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By including a <em>width</em> of <code>10</code>, the text is now nicely formatted into columns |
| of ten characters wide:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>---------- ---------- ---------- |
| 1.50 0.00 -3.57 |
| 2.34 3.75 5.78 |
| 4.71 12345.34 -3.12 |
| -3.25 1.25 99.20</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first line is not actual output, but is included to make it easier to see |
| the columns. Not only is the output now nicely put in columns, but due to the |
| exactly two digits after the dot (<code>.</code>), the dots are now also nicely aligned.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-large-numbers">Large numbers</h8> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%.2f", time);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>When simulated, this could give the following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>0.00 |
| 1.34 |
| 5000.23 |
| 2147185402.17</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As the values of variable <code>time</code> get larger and larger, their textual |
| representations become longer and longer, and it becomes more and more |
| difficult to see exactly how large the values are. The following alternative |
| CIF specification solves this problem:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%,.2f", time);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The addition of the comma (<code>,</code>) <em>flag</em> ensures that we get the following |
| output instead:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>0.00 |
| 1.34 |
| 5,000.23 |
| 2,147,185,402.17</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>That is, a comma is used in the result as <em>thousand separator</em>, making it |
| easier to see that the value of variable <code>time</code> is just over two billion, |
| rather than for instance just over 200 million.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-left-alignment">Left alignment</h8> |
| <div class="paragraph"> |
| <p>Earlier, we put values in columns. By default, if a <em>width</em> is used, text is |
| right-justified (aligned to the right). We can also justify it to the left, |
| as in this CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%-10.2d %-10.2d %-10.2d", g, h, i);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here the <code>%d</code> specifier is used instead of the <code>%f</code> specifier. The <code>%d</code> |
| specifier can only be used for integer values, while the <code>%f</code> specifier can |
| only be used for real values. Besides a different specifier, the minus (<code>-</code>) |
| flag is added, and different variables are used as values. After the changes, |
| the CIF specification could result in the following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>---------- ---------- ---------- |
| 184 3675 2 |
| 19350 29 -2956 |
| -17 -964563 235 |
| 2946 567 -25072563</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Once again, the first line is not actual output, but is included to make it |
| easier to see the columns. Observe how the addition of the <code>-</code> flag resulted |
| in the right-justified output being changed to left-justified (aligned to the |
| left) output. The presence of negative numbers makes that the left-most digits |
| of the columns are not nicely aligned. The following CIF specification solves |
| this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%-+10.2d %-+10.2d %-+10.2d", x, y, z);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The addition of the plus (<code>+</code>) flag means that for non-negative numbers, a |
| plus (<code>+</code>) character is always included:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>---------- ---------- ---------- |
| +184 +3675 +2 |
| +19350 +29 -2956 |
| -17 -964563 +235 |
| +2946 +567 -25072563</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If preferred, a space can be used instead of a plus, resulting in the following |
| CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print fmt("%- 10.2d %- 10.2d %- 10.2d", x, y, z);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>and the following output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>---------- ---------- ---------- |
| 184 3675 2 |
| 19350 29 -2956 |
| -17 -964563 235 |
| 2946 567 -25072563</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-more-formatting">More formatting</h8> |
| <div class="paragraph"> |
| <p>In this short tutorial, we’ve seen a few forms of text formatting using the |
| <code>fmt</code> function. However, CIF supports various other specifiers, besides the |
| <code>%s</code>, <code>%f</code>, and <code>%d</code> specifiers that were used in this tutorial. All |
| those specifiers support various flags, widths, and precisions, and allow them |
| to be combined in various ways. For the complete details of text formatting, |
| see the <a href="#tools-cifsim-output-print-chapter-ref-fmt">Text formatting details</a> page.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-ref-printdecl">Print declaration</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The core concept of print output is the <em>print declaration</em>. The print |
| declarations allow specifying what to print. They also optionally allow |
| specifying when to print it, how to print it, and to where to print it.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-transition-centric-view">Transition centric view</h8> |
| <div class="paragraph"> |
| <p>Unlike many programming languages that have print statements, CIF has print |
| declarations. Print declarations are |
| <a href="http://en.wikipedia.org/wiki/Declarative_programming">declarative</a>, |
| rather than |
| <a href="http://en.wikipedia.org/wiki/Imperative_programming">imperative</a>. |
| Print |
| declarations center on transitions. The following is a schematic overview of |
| a transition:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/print/transition.png" alt="transition"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The transition is graphically depicted as an arrow, with a label. The label |
| denotes the event that occurred, or <code>time</code> for time transitions. Every |
| transition has a <em>pre</em> or <em>source</em> <a href="#tools-cifsim-traces-state">state</a>, |
| and a <em>post</em> or <em>target</em> state. The states are graphically depicted as circles, |
| with a name above them. These names are only used so that they can be referred |
| to from the text.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The figure thus contains the transition and its immediate environment (its |
| source and target states). Print declarations allow specifying what, how, and |
| when to print, for transitions. Since the transition is the central part, we |
| call this the <em>transition centric view</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-extended-trace">Extended trace</h8> |
| <div class="paragraph"> |
| <p>Simulation using the CIF simulator results in a |
| <a href="#tools-cifsim-traces-traces">trace</a>. A trace consists of the |
| <a href="#tools-cifsim-traces-state">states</a> that are encountered and the |
| transitions that are taken, during the simulation. For instance, consider the |
| following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton buffer: |
| event add, remove; |
| disc int cnt = 5; |
| |
| location: |
| initial; |
| edge add when cnt < 10 do cnt := cnt + 1; |
| edge remove when cnt > 0 do cnt := cnt - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>buffer</code> initially contains five items (<code>cnt = 5</code>). As long as there |
| is room in the buffer (<code>cnt < 10</code>), an item can be added (event <code>add</code>) to |
| the buffer. As long as the buffer is not empty (<code>cnt > 0</code>), an item can be |
| removed (event <code>remove</code>) from the buffer. The following is a potential |
| simulation trace:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/print/trace_normal.png" alt="trace normal"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the initial state (S1), variable <code>cnt</code> has value <code>5</code>. An item is then |
| added (transition for the event <code>add</code>), resulting in a new state (S2), where |
| <code>cnt</code> has value <code>6</code>. After that, another item is added, leading to state |
| S3, where <code>cnt</code> has value <code>7</code>. Finally, an item is removed by means of a |
| transition for event <code>remove</code>, leading to state S4, where <code>cnt</code> has value |
| <code>6</code> again.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As can be seen in the figure, the initial state (S1) has no incoming |
| transition. Furthermore, the last/final state (S4) has no outgoing |
| transition. As we’ll see later, that poses some difficulties in applying the |
| transition centric view. To get around these limitations, the trace is extended |
| as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/print/trace_extended.png" alt="trace extended"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>A transition with the <em>initial</em> label is added before the initial state, and a |
| transition with the <em>final</em> label is added after the final state. This ensures |
| that all states have an incoming and outgoing transition. These two added |
| transitions are <em>virtual</em>, they don’t actually exist. They are added only for |
| the benefit of print output. That is, they don’t affect the simulation behavior |
| of the model, and are thus not part of the 'real' trace.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The added 'initial' virtual transition has no source state, and the added |
| 'final' virtual transition has no target state. Since in the transition centric |
| view every transition should have a source and a target state, we add the |
| initial state (S1) as source state (S0) for the 'initial' transition, and the |
| final state (S4) as target state (S5) for the 'final' transition. This way, |
| every transition (whether virtual or real) has a source and target state, and |
| fits the transition centric view. For the 'initial' and 'final' virtual |
| transitions, the source and target states are thus the same (S0 = S1, S4 = S5).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The trace with added virtual 'initial' and 'final' transitions, and with the |
| duplicates (S0 and S5) of the source and final states, is called the |
| <em>extended trace</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-specifying-the-text-to-print">Specifying the text to print</h8> |
| <div class="paragraph"> |
| <p>Every print declaration must specify <em>what</em> to print, using CIF expressions. |
| These CIF expressions can for instance refer to variables from the CIF model. |
| Since variables can change values, it is important to know in which state the |
| expression is evaluated. In the transition centric view, we have two states to |
| choose from, the pre/source state and the post/target state. The following |
| variants are supported to specify what to print:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print EXPR; |
| print pre EXPR; |
| print post EXPR; |
| print pre EXPR post EXPR;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first variant has only one expression, which is printed in the post/target |
| state. The third variant is identical, but explicitly indicates that the |
| post/target state is used. The second variant also has a single expression, but |
| is evaluated in the pre/source state. The fourth variant has two expression, |
| one of which is evaluated in the pre/source state, and one of which is |
| evaluated in the post/target state. The first three variants only print one |
| piece of text per transition, while the fourth variant prints two pieces of |
| text per transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print "a"; |
| print pre x post x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first example prints <code>a</code> after each transition. The second example prints |
| the value of variable <code>x</code> as it was before the transition, as well as the |
| value of variable <code>x</code> as it is after the transition, for each transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-quoting-and-escaping">Quoting and escaping</h8> |
| <div class="paragraph"> |
| <p>The expressions that indicate what text to print may be of any type, and the |
| result of evaluating the expression is converted to a textual representation |
| that closely resembles the textual syntax of CIF. For string literals this |
| means that the text is escaped, and double quotes are added. If however the |
| result of the expression is a <code>string</code> typed value, then that string is used |
| 'as is' (without quoting, and without escaping). Thus, consider the following |
| example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print ["a\"b"]; |
| print "a\"b";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first print declaration prints a list that contains a single string value, |
| while the second print declaration prints the single string value directly. |
| This results in the following printed output:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">["a\"b"] |
| a"b</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>That is, in general string values are quoted and escaped, as is the case for |
| the first example, where the result is a list. However, if the entire result |
| is a string, as is the case with the second example, the string value is used |
| 'as is', without quoting and without escaping.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-transition-filtering">Transition filtering</h8> |
| <div class="paragraph"> |
| <p>It is possible to filter the transitions to which print declarations apply, by |
| looking at the kind of the transitions (their labels). The following transition |
| filters are available:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 14.2857%;"> |
| <col style="width: 28.5714%;"> |
| <col style="width: 57.1429%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Filter</th> |
| <th class="tableblock halign-left valign-top">Matches</th> |
| <th class="tableblock halign-left valign-top">Does not match</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>event</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All event transitions, including those for the <code>tau</code> event.</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All time and virtual transitions.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>time</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All time transitions.</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All event and virtual transitions.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">e</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All transitions for event <code>e</code>.</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All time and virtual transitions, as well as all transitions for |
| 'other' events (including those for the <code>tau</code> event).</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>initial</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The single virtual <em>initial</em> transition.</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All event and time transitions, as well as the single virtual <em>final</em> transition.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>final</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The single virtual <em>final</em> transition.</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">All event and time transitions, as well as the single virtual <em>initial</em> transition.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Transition filters may be combined, leading to a combined transition filter |
| that matches if any of the individual transition filters matches. The |
| individual filters must be separated by commas.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Transition filtering is optional. If no transition filter is supplied, the |
| default transition filter is used, which is <code>initial, event, time</code>. That is, |
| by default output is printed for all transitions, except for the <em>final</em> |
| virtual transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print EXPR for e; |
| print EXPR for time, event; |
| print EXPR for initial, final; |
| print EXPR for machine1.start, machine2.start; |
| print EXPR;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first example prints only for transitions for event <code>e</code>. That is, time |
| transitions and virtual transitions, as well as transitions for all other |
| events, are filtered out. The second example prints only for event and time |
| transitions, and thus filters out the virtual transitions. The third example |
| prints only for the virtual transitions, and thus filters out all 'real' |
| transitions (the event and time transitions). The fourth example prints only |
| for transitions for the <code>start</code> events declared in <code>machine1</code> and |
| <code>machine2</code> (which could for instance be automata), and filters out time |
| transitions, virtual transitions, and transitions for all other events. The |
| fifth example does not specify a filter, and thus prints for the <em>initial</em> |
| virtual transition, as well as all event and time transitions, but excludes |
| the <em>final</em> virtual transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-state-filtering">State filtering</h8> |
| <div class="paragraph"> |
| <p>It is possible to filter the transitions to which print declarations apply, |
| by looking at the pre/source and post/target states of the transitions. |
| The following variants are supported for state filtering:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print EXPR when PRED; |
| print EXPR when pre PRED; |
| print EXPR when post PRED; |
| print EXPR when pre PRED post PRED;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first variant has only one predicate, which is evaluated in the post/target |
| state. The third variant is identical, but explicitly indicates that the |
| post/target state is used. For both these variants, text is only printed if the |
| post/target state satisfies the given predicate. That is, if the predicate |
| evaluated in the post/target state of the transition results in value <code>true</code>, |
| text may be printed. Otherwise, no text is printed for that transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second variant also has a single predicate, but is evaluated in the |
| pre/source state. Text is thus only printed if the pre/source state satisfies |
| the given predicate.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The fourth variant has two predicates, one of which is evaluated in the |
| pre/source state, and one of which is evaluated in the post/target state. Text |
| is only printed if the pre/source state satisfies the first predicate, and the |
| post/target state satisfies the second predicate. If either of the states does |
| not satisfy its corresponding predicate, no text is printed for that |
| transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print "a"; |
| print "b" when aut.loc; |
| print "c" when pre aut.loc; |
| print "d" when pre x mod 2 = 0 post x mod 2 = 1;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first example prints <code>a</code> after each transition, and does not restrict the |
| pre/source or post/target states. The second example only prints <code>b</code> for |
| transitions that end in location <code>loc</code> of automaton <code>aut</code>. The third |
| example only prints <code>c</code> for transitions that start in location <code>loc</code> of |
| automaton <code>aut</code>. The fourth example only prints <code>d</code> for transitions where |
| the value of variable <code>x</code> is even before the transition, and odd after the |
| transition.</p> |
| </div> |
| <div class="paragraph"> |
| <p>State filtering is thus optional. If no pre/source state predicate is |
| specified, the default is <code>true</code>. Similarly, if no post/target state |
| predicate is specified, the default is <code>true</code> as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-combining-filters">Combining filters</h8> |
| <div class="paragraph"> |
| <p>The transition and state filters are all optional. If however both a transition |
| filter and a state filter are specified, they must both match in order for text |
| to be printed. Consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print time for time when time > 3; |
| print x for e when pre x < 3 post x > 5; |
| print pre y post y when pre y = 5;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For the first example, the value of variable <code>time</code> is printed after time |
| transitions, if after those time transitions the value of variable <code>time</code> is |
| strictly larger than three. For the second example, the value of variable <code>x</code> |
| is printed after transitions for event <code>e</code> if before such transitions the |
| value of variable <code>x</code> is strictly less than three, and after such transitions |
| the value of variable <code>x</code> is strictly larger than <code>5</code>. For the third |
| example, the value of variable <code>y</code> is printed twice for all 'default' |
| transitions, once in the pre/source state, and once in the post/target state, |
| but only if the value of variable <code>y</code> before the transition is exactly five. |
| So if the condition over the pre/source state does not hold, the value of |
| variable <code>y</code> is not printed, not for the pre/source state, and also not for |
| the post/target state.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-printdecl-file">Output file/target</h8> |
| <div class="paragraph"> |
| <p>By default text is printed to the console, to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard output stream</a>, |
| usually called 'stdout'. It |
| is however possible to explicitly specify the file or special target to which |
| the output is to be printed. Consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print ... file "txt_files/some_file.txt"; |
| print ... file "../files/some_file.txt";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For the first print declaration, the simulator will look for a <code>txt_files</code> |
| directory in the same directory as the CIF file, and print text to a file named |
| <code>some_file.txt</code> in that directory. For the second print declaration, the |
| simulator will look for a <code>files</code> directory in the parent directory of the |
| directory that contains the CIF file, and print text to a file named |
| <code>some_file.txt</code> in that <code>files</code> directory.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Files and directories are separated using slashes (<code>/</code>), regardless of the |
| used operating system. It is also allowed to use backslashes (<code>\</code>), which are |
| more common on Microsoft Windows operating systems, but they need to be escaped |
| as <code>\\</code> for this to work, making it easier to use slashes (<code>/</code>) instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following special non-file targets are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>":stdout"</code>: prints to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard output stream</a>. |
| In Eclipse, the text ends up on the console, as black text.</p> |
| </li> |
| <li> |
| <p><code>":stderr"</code>: prints to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard error stream</a>. |
| In Eclipse, the text ends up on the console, as red text.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Besides these local file indications, CIF also supports global |
| <a href="#tools-cifsim-output-print-chapter-ref-printfile">print file declarations</a>, |
| which influence the default, in case no local file or special target is |
| specified.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-scoping">Scoping</h8> |
| <div class="paragraph"> |
| <p>Print file declarations can be specified in all components. That is, they can |
| be specified in the top level scope of the specification, in groups and group |
| definitions, as well as in automata and automaton definitions.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-ref-printfile">Print file declaration</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| <a href="#tools-cifsim-output-print-chapter-ref-printdecl">Print declarations</a> can |
| <a href="#tools-cifsim-output-print-ref-printdecl-file">specify</a> the file or |
| special target to which text is to printed. If they don’t specify anything, |
| the default is to print to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard output stream</a>, |
| usually called 'stdout'. |
| This default can be influenced by means of <em>print file declarations</em>, which act |
| as a sort of global declaration of the file or special target. A typical print |
| file declaration looks like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "some_file.txt";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-paths">Paths</h8> |
| <div class="paragraph"> |
| <p>It is possible to use relative (or absolute) paths for the files. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "txt_files/some_file.txt"; |
| printfile "../files/some_file.txt";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For the first print file declaration, the simulator will look for a |
| <code>txt_files</code> directory in the same directory as the CIF file, and print text |
| to a file named <code>some_file.txt</code> in that directory. For the second print file |
| declaration, the simulator will look for a <code>files</code> directory in the parent |
| directory of the directory that contains the CIF file, and print text to a file |
| named <code>some_file.txt</code> in that <code>files</code> directory.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Files and directories are separated using slashes (<code>/</code>), regardless of the |
| used operating system. It is also allowed to use backslashes (<code>\</code>), which are |
| more common on Microsoft Windows operating systems, but they need to be escaped |
| as <code>\\</code> for this to work, making it easier to use slashes (<code>/</code>) instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-special-targets">Special targets</h8> |
| <div class="paragraph"> |
| <p>The following special non-file targets are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>":stdout"</code>: prints to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard output stream</a>. |
| In Eclipse, the text ends up on the console, as black text.</p> |
| </li> |
| <li> |
| <p><code>":stderr"</code>: prints to the |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard error stream</a>. |
| In Eclipse, the text ends up on the console, as red text.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-scoping-2">Scoping</h8> |
| <div class="paragraph"> |
| <p>Print file declarations can (just as print declarations) be specified in all |
| components. That is, they can be specified in the top level scope of the |
| specification, in groups and group definitions, as well as in automata and |
| automaton definitions. A print file declaration that is specified in a certain |
| scope applies to that scope, as well as all child scopes that don’t have a |
| print file declaration of their own. Additionally, print file declarations |
| apply to all print declarations without local file declarations, in scopes to |
| which the print file declarations apply.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "file1.txt"; |
| |
| print 5; |
| print 6 file "file2.txt"; |
| |
| group g: |
| printfile "file3.txt"; |
| |
| print 7; |
| print 8; |
| print 9 file "file4.txt"; |
| |
| group h: |
| printfile "file5.txt"; |
| end |
| |
| group i: |
| print 10; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The print declaration that prints <code>5</code> is declared in the top level scope of |
| the specification, and does not have a local file declaration. As such, the |
| print file declaration from the top level scope (<code>file1.txt</code>) applies to it. |
| The print declaration that prints <code>6</code> is declared in the same scope, but has |
| a local print file declaration (<code>file2.txt</code>). The local print file |
| declaration (<code>file2.txt</code>) overrides the print file declaration from the top |
| level scope (<code>file1.txt</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g</code> also has a print file declaration (<code>file3.txt</code>). This overrides |
| the print file declaration from the top level scope (<code>file1.txt</code>). The print |
| file declaration from group <code>g</code> (<code>file3.txt</code>) thus applies to the print |
| declarations that print <code>7</code> and <code>8</code>, as they are declared in the same |
| scope, and don’t have local print file declarations. The print declaration that |
| prints <code>9</code> has a local print file declaration (<code>file4.txt</code>), and as such |
| the print file declaration from group <code>g</code> (<code>file3.txt</code>) does not apply to |
| it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The print file declaration (<code>file5.txt</code>) from group <code>g.h</code> does not apply to |
| any print declarations. The simulator will open the file for writing, but no |
| text will be printed to the file. A warning is printed to the console, to |
| indicate the potential problem. However, no such warnings are ever printed for |
| special target 'stdout'.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g.i</code> does not have a print file declaration, so the print file |
| declaration (<code>file3.txt</code>) from group <code>g</code> (the parent scope of group |
| <code>g.i</code>) applies to the print declaration that prints <code>10</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also the <a href="#tools-cif2cif-chapter-print-file-into-decls">Push print file declarations into print declarations</a> CIF to CIF |
| transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-uniqueness-2">Uniqueness</h8> |
| <div class="paragraph"> |
| <p>In every scope (or component), in principle at most one print file declaration |
| may be specified. The exception is that for a single scope, specified in |
| multiple CIF files (when imports are used), if the print file declarations |
| refer to the same target, they are merged. If however the two CIF files refer |
| to different targets, this is still considered an error. It is also considered |
| an error if two print file declarations are present in a single scope, in a |
| single file, regardless of whether they refer to the same target or not. In |
| the end, after processing imports, for every scope there must be a unique print |
| file declaration, if one is declared at all.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the same file or special target is used/specified multiple times, in |
| different print file declarations or locally in print declarations, this is |
| detected by the simulator. The simulator only opens a stream to the file or |
| special target once, and prints to it all the output of all print declarations |
| that apply to that file or special target. For instance, consider the following |
| CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print 5 file "some_file.txt"; |
| print 6 file "some_file.txt";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Even though both print declarations specify a file locally, they use the same |
| file. The output of both print declarations is thus printed to the same file.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-ref-sim">Simulation with print output</h7> |
| <div class="paragraph"> |
| <p> |
| Once a CIF specification with print declarations is available, the simulator |
| can be used to generate textual output. This page discusses the following |
| simulation related topics:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-ref-sim-overwrite">Overwriting files</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-ref-sim-line-based">Line-based output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-ref-sim-order">Output order</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-ref-sim-enable-disable">Enabling/disabling print output</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-sim-overwrite">Overwriting files</h8> |
| <div class="paragraph"> |
| <p>If output is printed to files, those files are always overwritten for each |
| simulation. That is, at the start of the simulation, the output file is removed |
| if present. A new empty file is then created, to which the output is printed |
| during the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-sim-line-based">Line-based output</h8> |
| <div class="paragraph"> |
| <p>Output is printed in a line-based fashion. That is, every time text is printed |
| for a <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print declaration</a>, the |
| text is printed on a new line. If a single print declaration has two texts, one |
| for the pre/source state and one for the post/target state, both texts are |
| printed on new lines.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-sim-order">Output order</h8> |
| <div class="paragraph"> |
| <p>The simulator guarantees that once text is printed for a certain state, no text |
| shall ever be printed during that same simulation, for previous states. That |
| is, output text is ordered by 'increasing' states. This guarantee holds for |
| file output. For the special targets |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard output stream</a> |
| (stdout) and |
| <a href="http://en.wikipedia.org/wiki/Standard_streams">standard error stream</a> |
| (stderr), the output may get mixed, for instance on the Eclipse console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The order in which text is printed for different print declarations that print |
| text for the same state, is determined by the order in which the print |
| declarations are specified in the CIF specification, from top to bottom. The |
| order is determined per file or special target, after elimination of imports, |
| component definition/instantiation, etc. A depth-first traversal of the |
| component hierarchy is used, where the print declarations of components are |
| considered before the print declarations of their children.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-sim-enable-disable">Enabling/disabling print output</h8> |
| <div class="paragraph"> |
| <p>Print output is enabled by default. It can be disabled by reducing the |
| types of <a href="#tools-cifsim-output-chapter-normal">normal console output</a> using the |
| <b class="menuref">Normal output</b> |
| option (<b class="menuref">Output</b> |
| category). Using that |
| option it is also possible to disable all other forms of normal output, to be |
| able to see only the print output on the console. Print output can also be |
| disabled by changing the <a href="#tools-cifsim-output-mode">output mode</a> to |
| <em>Error</em> or to <em>Warning</em>, instead of <em>Normal</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-undoreset-2">Undo/reset</h8> |
| <div class="paragraph"> |
| <p>By <a href="#tools-cifsim-input-history-reset-undo">undoing</a> one or more transitions, |
| or by <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation, the |
| state may change. However, only previously taken transitions are undone. No new |
| transitions are taken by undoing transitions, or by resetting the simulation. |
| As such, no new print output is generated.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-print-chapter-ref-fmt">Text formatting details</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| For text formatting, CIF features the <code>fmt</code> standard library function. This |
| page describes all the details of using that function. For more introductory |
| information and examples of the use of the <code>fmt</code> function for print output, |
| see the <a href="#tools-cifsim-output-print-chapter-tut-fmt">Text formatting tutorial</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-pattern">Format patterns</h8> |
| <div class="paragraph"> |
| <p>The <code>fmt</code> function requires at least one argument, the <em>format pattern</em>. The |
| remaining arguments of the function are the <em>values</em> that can be inserted into |
| the format pattern, to allow variable output. For instance, consider:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%s %s", x, y)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, <code>"%s %s"</code> is the format pattern, <code>x</code> is the first value, and <code>y</code> is |
| the second value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first argument, the format pattern, must be a string literal. That is, it |
| must be text between double quotes (<code>"</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The real usefulness of format patterns comes from the inclusion of the values |
| into the format pattern. The values can be included by inserting format |
| specifiers (e.g. <code>%s</code>) into the format pattern. Multiple values may be used |
| by including multiple format specifiers. The first format specifier includes |
| the first value, the second format specifier includes the second value, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The result of <code>fmt</code> applied to it arguments is the text of the format |
| pattern, with the format specifiers replaced by their corresponding values.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Format specifiers can be customized to influence how their corresponding values |
| are to be inserted. For instance, consider:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%s %.2e", x, y)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Then, assuming variable <code>x</code> has value <code>3</code> and variable <code>y</code> has value |
| <code>5.6</code>, the result of the <code>fmt</code> function is <code>3 5.60e+00</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-specifiers">Specifiers</h8> |
| <div class="paragraph"> |
| <p>Format patterns support various types of format specifiers, each performing a |
| different kind of conversion on its corresponding value. The following table |
| lists the available conversions, the types of values that they support, and a |
| short description of the output of the conversion:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 25%;"> |
| <col style="width: 25%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Conversion</th> |
| <th class="tableblock halign-left valign-top">Supported types</th> |
| <th class="tableblock halign-left valign-top">Output</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-b">%b</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Either <code>true</code> or <code>false</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-b">%B</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Same as <code>%b</code>, but in upper case.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-d">%d</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Decimal integer notation.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-x">%x</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Hexadecimal integer notation, using <code>0-9</code> and <code>a-f</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-x">%X</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Hexadecimal integer notation, using <code>0-9</code> and <code>A-F</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-e">%e</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Computerized scientific notation, using <code>e</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-e">%E</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Computerized scientific notation, using <code>E</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-f">%f</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Decimal number notation.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-g">%g</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">General scientific notation, using <code>e</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-g">%G</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">General scientific notation, using <code>E</code>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-s">%s</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">any type</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">General textual representation.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-output-print-ref-fmt-s">%S</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">any type</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">General textual representation, in upper case.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>For the <code>%d</code>, <code>%x</code>, and <code>%X</code> specifiers, <code>int</code> typed values are |
| supported, as are integer types with ranges (e.g. <code>int[0..5]</code>). The <code>%s</code> |
| and <code>%S</code> specifiers support values of any type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The output of the <code>%B</code> specifier is identical to the output of the <code>%b</code> |
| specifier, where all letters in the output are converted to upper case letters. |
| This duality (lower case specifier conversion versus upper case specifier |
| conversion) is present in all conversions that can have letters in their |
| output.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-syntax">Specifier syntax</h8> |
| <div class="paragraph"> |
| <p>Specifiers can be customized to influence the conversion of their corresponding |
| values to text. The general syntax of specifiers is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>%[value_index$][flags][width][.precision]conversion</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>All specifiers start with a percentage character (<code>%</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>They are optionally followed by a value index. If the value index is specified, |
| it must be followed by a dollar sign (<code>$</code>). The value index is a positive |
| decimal integer indicating the position of the value in the value list. The |
| first value is referenced by <code>1$</code>, the second by <code>2$</code>, etc. Index zero and |
| indices starting with zero are not allowed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The index is followed by optional flags. Flags are characters that modify the |
| output, and may be specified in any order. Each flag may only be specified once |
| per specifier. The set of valid flags depends on the conversion.</p> |
| </div> |
| <div class="paragraph"> |
| <p>After the flags, an optional width may be specified. The width is a |
| non-negative decimal integer indicating the minimum number of characters that |
| should be included in the result, for that specific specifier.</p> |
| </div> |
| <div class="paragraph"> |
| <p>After the width, a precision may optionally be specified. A precision is always |
| preceded by a dot (<code>.</code>). The precision is a non-negative decimal integer used |
| to restrict the number of characters. The specific behavior depends on the |
| conversion.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Specifiers always end with the character indicating the conversion to perform.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-indexing">Implicit and explicit indexing</h8> |
| <div class="paragraph"> |
| <p>By default, format specifiers are processed in order. The first specifier then |
| implicitly uses the first value, the second specifier implicitly uses the |
| second value, etc. However, if an explicit value index is given, that explicit |
| index indicates the value to use, and the specifier with the explicit index |
| does not influence subsequent implicit indexing. That is, consider the |
| following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%s %1$s %3$f %d %f %1$s", 1, 2, 3.0);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first specifier (<code>%s</code>) does not specify an explicit index, and thus |
| implicitly uses the first value. The second specifier (<code>%1$s</code>) explicitly |
| specifies index <code>1</code> and thus uses the first value. The third specifier |
| (<code>%3$f</code>) explicitly specifies index <code>3</code> and thus uses the third value. The |
| fourth specifier (<code>%d</code>) is the second specifier to not explicitly specify an |
| index, and thus implicitly uses the second value. The fifth specifier (<code>%f</code>) |
| is the third specifier to not explicitly specify an index, and thus implicitly |
| uses the third value. Finally, the sixth specifier (<code>%1$s</code>) explicitly |
| specifies index <code>1</code>, and thus uses the first value. The result of the |
| formatting is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>1 1 3.000000 2 3.000000 1</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-flags">Flags</h8> |
| <div class="paragraph"> |
| <p>The following flags are available:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 7.1428%;"> |
| <col style="width: 42.8576%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Flag</th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-b">b/B</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-d">d</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-x">x/X</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-e">e/E</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-f">f</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-g">g/G</a></th> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-output-print-ref-fmt-s">s/S</a></th> |
| <th class="tableblock halign-left valign-top">Effect</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>-</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The result will be left-justified.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>+</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The result will always include a sign.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">(space)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The result will include a leading space for non-negative values.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>0</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The result will be zero-padded.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>,</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The result will include commas (<code>,</code>) as grouping separator.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>The first column shows the available flags, the minus (<code>-</code>), the plus |
| (<code>+</code>), the space, the zero (<code>0</code>), and the comma (<code>,</code>). The middle columns |
| indicate for each of the different conversions, whether the flags are |
| supported. The last column gives short descriptions of the effects of the |
| flags.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>-</code> flag can be used to left-justify the text in case a |
| <a href="#tools-cifsim-output-print-ref-fmt-width">width</a> is used, as the default |
| is to right-justify. It is supported by all format specifiers. The <code>-</code> flag |
| requires the use of a width, and can not be combined with the <code>0</code> flag.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>+</code> flag can be used to always include a sign. It only applies to certain |
| numeric format specifiers. That is, by default non-negative numbers don’t have |
| a sign, and negative numbers start with a <code>-</code> character. By including the |
| <code>+</code> flag, non-negative numbers start with a <code>+</code> character, and negative |
| numbers still start with a <code>-</code> character. The <code>+</code> and space flags can not |
| be combined.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The space flag can be used force a leading space to be included for |
| non-negative values. It only applies to certain numeric format specifiers. That |
| is, by default non-negative numbers don’t have a sign, and negative numbers |
| start with a <code>-</code> character. By including the space flag, non-negative numbers |
| start with a space character, and negative numbers still start with a <code>-</code> |
| character. The <code>+</code> and space flags can not be combined.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>0</code> flag can be used to zero pad numbers, in case a |
| <a href="#tools-cifsim-output-print-ref-fmt-width">width</a> is used, the text is |
| right-justified, and the text is shorter than the width. It only applies to |
| certain numeric format specifiers. The <code>0</code> flag requires the use of a width, |
| and can not be combined with left-justification (the <code>-</code> flag).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>,</code> flag can be used to include commas (<code>,</code>) as grouping separators. |
| It only applies to certain numeric format specifiers. That is, by default |
| numbers are just a sequence of digits. By using the <code>,</code> flag, longer numbers |
| are placed in groups of thousands and the 'thousands separator' (the <code>,</code> |
| character) occurs every three digits. For instance, <code>12345678</code> would then |
| become <code>12,345,678</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Further details on the effects of flags are given in the sections describing |
| the individual conversions.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-width">Width</h8> |
| <div class="paragraph"> |
| <p>The width is a non-negative decimal integer indicating the minimum number of |
| characters that should be included in the result, for that specific specifier. |
| If no width is given, there is no minimum number of characters.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the textual representation of the value is shorter than the width, the |
| text is right-justified. That is, the text will be padded by spaces to the |
| left of the text until the total number of characters equals the width. To |
| left-justify the text, use the <code>-</code> flag in combination with a width. This |
| results in padding with spaces to the right of the text.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the <code>0</code> flag is specified, and the textual representation of the value is |
| shorter than the width, <code>0</code> padding is used (to the left, as the <code>-</code> flag |
| may not be used when the <code>0</code> flag is used). See the sections describing the |
| individual number related specifiers for further details.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the text is longer than the width, the whole text is included in the result |
| (it is not truncated), and the width essentially has no effect.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-b"><code>%b</code> and <code>%B</code> specifiers</h8> |
| <div class="paragraph"> |
| <p>The <code>%b</code> and <code>%B</code> specifiers convert boolean values to text. The specifiers |
| only support boolean values. The specifiers support explicit indices, widths, |
| and the <code>-</code> flag. They don’t supports any of the other flags, and precisions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Value <code>true</code> results in the text <code>true</code>, and value <code>false</code> results |
| in the text <code>false</code>.</p> |
| </li> |
| <li> |
| <p>For the <code>%B</code> specifier, the text is converted to upper case, i.e. |
| <code>TRUE</code> and <code>FALSE</code> respectively.</p> |
| </li> |
| <li> |
| <p>If a width is specified, and the resulting text so far is shorter than that |
| width, spaces are added until the given width is reached. If the <code>-</code> flag |
| is given, spaces are added to the right, otherwise spaces are added to the |
| left.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>b</code> has value <code>true</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%b", b); // true |
| fmt("%B", b); // TRUE |
| fmt("_%10b_", b); // _ true_ |
| fmt("_%-10b_", b); // _true _</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-d"><code>%d</code> specifier</h8> |
| <div class="paragraph"> |
| <p>The <code>%d</code> specifier converts integer numbers to text, using decimal |
| representations of integers. The specifier only support integer values |
| (<code>int</code> typed values, and values of integer types with ranges, such as |
| <code>int[0..5]</code>). The specifier supports explicit indices, widths, and all flags. |
| It doesn’t support precisions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The resulting text is initialized to the decimal representation of the |
| absolute value of the integer number. It thus consists of only the digits |
| <code>0</code> through <code>9</code>.</p> |
| </li> |
| <li> |
| <p>If the <code>,</code> flag is given, thousand separators (<code>,</code> characters) are |
| inserted as needed, for longer numbers.</p> |
| </li> |
| <li> |
| <p>If the number is negative, it is prefixed with a <code>-</code> character.</p> |
| </li> |
| <li> |
| <p>If the number is non-negative, and the space flag is given, a space is added |
| before the text.</p> |
| </li> |
| <li> |
| <p>If the number is non-negative, and the <code>+</code> flag is given, a <code>+</code> character |
| is added before the text.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>0</code> |
| flag is given, then <code>0</code> characters are added before the other digits, and |
| after any non-digit characters, until the desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>-</code> |
| flag is given, then space characters are added before the result, until the |
| desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and neither |
| the <code>0</code> flag nor the <code>-</code> flag is given, then space characters are added |
| after the result, until the desired width is reached.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>x</code> has value <code>12345</code> and <code>y</code> has value |
| <code>-2345</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%d", x); // 12345 |
| fmt("%,d", x); // 12,345 |
| fmt("_%10d_", x); // _ 12345_ |
| fmt("_%-10d_", x); // _12345 _ |
| fmt("_%0,10d_", x); // _000012,345_ |
| fmt("_%- 10d_", x); // _ 12345 _ |
| fmt("_%- 10d_", y); // _-2345 _ |
| fmt("_%-+10d_", x); // _+12345 _ |
| fmt("_%-+10d_", y); // _-2345 _ |
| fmt("_%3d_", x); // _12345_</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-x"><code>%x</code> and <code>%X</code> specifiers</h8> |
| <div class="paragraph"> |
| <p>The <code>%x</code> and <code>%X</code> specifiers convert integer numbers to text, using |
| hexadecimal representations of integers. The specifiers only support integer |
| values (<code>int</code> typed values, and values of integer types with ranges, such as |
| <code>int[0..5]</code>). The specifiers supports explicit indices, widths, and the <code>-</code> |
| and <code>0</code> flags. They don’t supports any of the other flags, and precisions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The signed integer number in range [-2,147,483,648 .. 2,147,483,647] is |
| first converted to an unsigned integer number in range [0 .. 4,294,967,295]. |
| That is, for negative numbers, 2<sup>32</sup> is added.</p> |
| </li> |
| <li> |
| <p>The resulting text is initialized to the hexadecimal representation of the |
| unsigned integer number. It thus consists the digits <code>0</code> through <code>9</code> and |
| letters <code>a</code> through <code>f</code>.</p> |
| </li> |
| <li> |
| <p>For the <code>%X</code> specifier, the text is converted to upper case, i.e. letters |
| <code>a</code> through <code>f</code> are converted to letters <code>A</code> through <code>F</code>.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>0</code> |
| flag is given, then <code>0</code> characters are added before the result, until the |
| desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>-</code> |
| flag is given, then space characters are added before the result, until the |
| desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and neither |
| the <code>0</code> flag nor the <code>-</code> flag is given, then space characters are added |
| after the result, until the desired width is reached.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>a</code> has value <code>5543</code> and <code>b</code> has value |
| <code>-1</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%x", a); // 15a7 |
| fmt("0x%x", a); // 0x15a7 |
| fmt("0x%X", a); // 0x15A7 |
| fmt("0x%X", b); // 0xFFFFFFFF |
| fmt("_%10x_", a); // _ 15a7_ |
| fmt("_%-10x_", a); // _15a7 _ |
| fmt("_%3x_", a); // _15a7_</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-e"><code>%e</code> and <code>%E</code> specifiers</h8> |
| <div class="paragraph"> |
| <p>The <code>%e</code> and <code>%E</code> specifiers convert real numbers to text, using |
| computerized scientific notation. The specifiers only support real |
| values. The specifiers supports explicit indices, widths, the <code>-</code>, <code>+</code>, |
| space, and <code>0</code> flags, and precisions. They don’t supports any of the other |
| flags.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Real numbers include a <em>decimal mark</em>, a symbol used to separate the integer |
| part from the fractional part of number, when written in decimal form. This |
| decimal mark is denoted by a dot (<code>.</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The decimal mark of the real number is shifted to ensure that at most one |
| non-zero digit occurs to the left of it. That is, for real numbers <code>0.012</code>, |
| <code>0.12</code>, <code>1.2</code>, <code>12.0</code>, and <code>120.0</code>, the decimal mark is shifted |
| -2, -1, 0, 1, and 2 digits to the left, respectively. This results in the |
| following real numbers: <code>1.2</code>, <code>1.2</code>, <code>1.2</code>, <code>1.2</code>, and <code>1.2</code>. |
| For zero, the decimal mark is not shifted.</p> |
| </li> |
| <li> |
| <p>The single decimal digit before the decimal mark is included in the result. |
| If there is no digit before the decimal mark (in case the real number is |
| zero), a single <code>0</code> digit is included in the result.</p> |
| </li> |
| <li> |
| <p>If the precision is specified and is not zero, or if the default precision |
| is used, a dot (<code>.</code>) is added after the single digit.</p> |
| </li> |
| <li> |
| <p>The digits after the decimal mark are added after the dot. Exactly |
| 'precision' digits will be added. If no precision is specified, it defaults |
| to <code>6</code> digits after the dot. If not enough digits are available after the |
| dot, additional <code>0</code> characters are added after them, to reach the desired |
| precision. If too many digits are available after the dot, digits are removed |
| from the right until the desired precision is reached. Rounding using the |
| 'half up' algorithm is used to ensure correct results in case digits are |
| removed.</p> |
| </li> |
| <li> |
| <p>If the <code>%e</code> specifier is used, an <code>e</code> character is added to the end. |
| If the <code>%E</code> specifier is used, an <code>E</code> character is added to the end.</p> |
| </li> |
| <li> |
| <p>A sign character is added after that. That is, if the decimal mark was |
| shifted a negative number of digits to the left, a <code>-</code> character is added, |
| otherwise a <code>+</code> character is added.</p> |
| </li> |
| <li> |
| <p>The number of digits that was shifted is added as a decimal number, at the |
| end. At least two decimal digits are added, so if the number of digits that |
| was shifted can be represented using a single decimal digit, a <code>0</code> is added |
| between the <code>e</code> or <code>E</code> character and the number of digits that was |
| shifted.</p> |
| </li> |
| <li> |
| <p>If the real number is negative, the text is prefixed with a <code>-</code> character.</p> |
| </li> |
| <li> |
| <p>If the real number is non-negative, and the space flag is given, a space is |
| added before the text.</p> |
| </li> |
| <li> |
| <p>If the real number is non-negative, and the <code>+</code> flag is given, a <code>+</code> |
| character is added before the text.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>0</code> |
| flag is given, then <code>0</code> characters are added before the other digits, and |
| after any non-digit characters, until the desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>-</code> |
| flag is given, then space characters are added before the result, until the |
| desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and neither |
| the <code>0</code> flag nor the <code>-</code> flag is given, then space characters are added |
| after the result, until the desired width is reached.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>a</code> has value <code>12345.6789</code> and <code>b</code> has |
| value <code>-0.00002345678</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%e", a); // 1.234568e+04 |
| fmt("%E", a); // 1.234568E+04 |
| fmt("%.3e", a); // 1.235e+04 |
| fmt("%.3e", b); // -2.346e-05 |
| fmt("_%20e_", a); // _ 1.234568e+04_ |
| fmt("_%-20e_", a); // _1.234568e+04 _ |
| fmt("_%5e_", a); // _1.234568e+04_ |
| fmt("_%020e_", a); // _000000001.234568e+04_ |
| fmt("_%-+20e_", a); // _+1.234568e+04 _ |
| fmt("_%-+20e_", b); // _-2.345678e-05 _ |
| fmt("_%- 20e_", a); // _ 1.234568e+04 _ |
| fmt("_%- 20e_", b); // _-2.345678e-05 _</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-f"><code>%f</code> specifier</h8> |
| <div class="paragraph"> |
| <p>The <code>%f</code> specifier converts real numbers to text, using a decimal number |
| notation. The specifier only supports real values. The specifier supports |
| explicit indices, widths, all flags, and precisions. That is, all features of |
| format specifiers are supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Real numbers include a <em>decimal mark</em>, a symbol used to separate the integer |
| part from the fractional part of number, when written in decimal form. This |
| decimal mark is denoted by a dot (<code>.</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The decimal digits before the decimal mark are included in the result. |
| If there are no digits before the decimal mark, a single <code>0</code> digit is |
| included in the result.</p> |
| </li> |
| <li> |
| <p>If the <code>,</code> flag is given, thousand separators (<code>,</code> characters) are |
| inserted as needed, for longer numbers.</p> |
| </li> |
| <li> |
| <p>If the precision is specified and is not zero, or if the default precision |
| is used, a dot (<code>.</code>) is added after the digits.</p> |
| </li> |
| <li> |
| <p>The digits after the decimal mark are added after the dot. Exactly |
| 'precision' digits will be added. If no precision is specified, it defaults |
| to <code>6</code> digits after the dot. If not enough digits are available after the |
| dot, additional <code>0</code> characters are added after them, to reach the desired |
| precision. If too many digits are available after the dot, digits are removed |
| from the right until the desired precision is reached. Rounding using the |
| 'half up' algorithm is used to ensure correct results in case digits are |
| removed.</p> |
| </li> |
| <li> |
| <p>If the real number is negative, the text is prefixed with a <code>-</code> character.</p> |
| </li> |
| <li> |
| <p>If the real number is non-negative, and the space flag is given, a space is |
| added before the text.</p> |
| </li> |
| <li> |
| <p>If the real number is non-negative, and the <code>+</code> flag is given, a <code>+</code> |
| character is added before the text.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>0</code> |
| flag is given, then <code>0</code> characters are added before the other digits, and |
| after any non-digit characters, until the desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and the <code>-</code> |
| flag is given, then space characters are added before the result, until the |
| desired width is reached.</p> |
| </li> |
| <li> |
| <p>If a width is given, the text so far is shorter than the width, and neither |
| the <code>0</code> flag nor the <code>-</code> flag is given, then space characters are added |
| after the result, until the desired width is reached.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>a</code> has value <code>12345.6789</code> and <code>b</code> has |
| value <code>-0.00002345678</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%f", a); // 12345.678900 |
| fmt("%f", b); // -0.000023 |
| fmt("%.3f", a); // 12345.679 |
| fmt("_%20f_", a); // _ 12345.678900_ |
| fmt("_%-20f_", a); // _12345.678900 _ |
| fmt("_%-,20f_", a); // _12,345.678900 _ |
| fmt("_%5f_", a); // _12345.678900_ |
| fmt("_%020f_", a); // _0000000012345.678900_ |
| fmt("_%-+20f_", a); // _+12345.678900 _ |
| fmt("_%-+20f_", b); // _-0.000023 _ |
| fmt("_%- 20f_", a); // _ 12345.678900 _ |
| fmt("_%- 20f_", b); // _-0.000023 _</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-g"><code>%g</code> and <code>%G</code> specifiers</h8> |
| <div class="paragraph"> |
| <p>The <code>%g</code> and <code>%G</code> specifiers convert real numbers to text, using general |
| scientific notation. The specifiers only support real values. The specifiers |
| supports explicit indices, widths, all flags, and precisions. That is, all |
| features of format specifiers are supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Real numbers include a <em>decimal mark</em>, a symbol used to separate the integer |
| part from the fractional part of number, when written in decimal form. This |
| decimal mark is denoted by a dot (<code>.</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the real number is is greater than or equal to 10<sup>-4</sup> but |
| less than 10<sup>precision</sup>, the result is as <code>%f</code>. Otherwise, the |
| result is as <code>%e</code> and <code>%E</code>, for <code>%g</code> and <code>%G</code> respectively. However, |
| the total number of |
| <a href="http://en.wikipedia.org/wiki/Significant_figures">significant digits</a> |
| of the |
| result is equal to the precision of the <code>%g</code> or <code>%G</code> specifier, and |
| defaults to <code>6</code> if not specified. If the specified precision is <code>0</code>, it is |
| taken to be <code>1</code> instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>a</code> has value <code>12345.6789</code> and <code>b</code> has |
| value <code>-0.00002345678</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%g", a); // 12345.7 |
| fmt("%g", b); // -2.34568e-05 |
| fmt("%G", b); // -2.34568E-05 |
| fmt("%.3g", a); // 1.23e+04 |
| fmt("_%20g_", a); // _ 12345.7_ |
| fmt("_%-20g_", a); // _12345.7 _ |
| fmt("_%-,20g_", a); // _12,345.7 _ |
| fmt("_%5g_", a); // _12345.7_ |
| fmt("_%020g_", a); // _000000000000012345.7_ |
| fmt("_%-+20g_", a); // _+12345.7 _ |
| fmt("_%-+20g_", b); // _-2.34568e-05 _ |
| fmt("_%- 20g_", a); // _ 12345.7 _ |
| fmt("_%- 20g_", b); // _-2.34568e-05 _</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-s"><code>%s</code> and <code>%S</code> specifiers</h8> |
| <div class="paragraph"> |
| <p>The <code>%s</code> and <code>%S</code> specifiers convert any value to text. The specifiers |
| support values of any type. The specifiers supports explicit indices, widths, |
| and the <code>-</code> flag. They don’t supports any of the other flags, and precisions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The resulting text is constructed as follows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>If the value has a <code>string</code> type, the value of that string is used as is, |
| without escaping and double quoting. Otherwise, the value is converted to |
| a textual representation closely resembling the CIF textual syntax (ASCII |
| syntax), with string values surrounded by double quotes, and with special |
| characters (tabs, new lines, double quotes, and backslashes) escaped.</p> |
| </li> |
| <li> |
| <p>For the <code>%S</code> specifier, the text is converted to upper case, i.e. letters |
| <code>a</code> through <code>z</code> are converted to letters <code>A</code> through <code>Z</code>.</p> |
| </li> |
| <li> |
| <p>If a width is specified, and the resulting text so far is shorter than that |
| width, spaces are added until the given width is reached. If the <code>-</code> flag |
| is given, spaces are added to the right, otherwise spaces are added to the |
| left.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Here are some examples, assuming <code>x</code> has value <code>"aBcD"</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("%s", x); // aBcD |
| fmt("%S", x); // ABCD |
| fmt("_%10s_", x); // _ aBcD_ |
| fmt("_%-10s_", x); // _aBcD _</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As indicated above, <code>string</code> typed values are of special interest. For |
| instance, consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("a %s b", ("some \\ text", 6)); // a ("some \\ text", 6) b |
| fmt("a %s b", "some \\ text"); // c some \ text d</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first example has a tuple as value, with a string and an integer number. |
| The output of this example is <code>a ("some \\ text", 6) b</code>. Note how the string |
| in the tuple is included in the output with double quotes around it, and how |
| the escaped backslash is also escaped in the resulting text.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second example has a value that is a string directly (e.g. not contained in |
| a tuple or some other container). This mapping results in <code>c some \ text d</code>. |
| Note how the string is included in the output 'as is', i.e. it is not |
| surrounded by double quotes, and the backslash is not escaped.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, when using a <code>%s</code> specifier, string values are double quoted and |
| escaped. If however the entire value is a string, then that string is used |
| 'as is' (without quoting, and without escaping).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Also of special interest are real values. The number of digits after the |
| decimal point can vary. For instance, consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">fmt("a %s b", 1 / 3); // a 0.3333333333333333 b |
| fmt("c %s d", 1 / 2); // c 0.5 d</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For more control over the number of digits after the decimal point, use one of |
| the floating point number format specifiers: |
| <a href="#tools-cifsim-output-print-ref-fmt-e">%e</a>, |
| <a href="#tools-cifsim-output-print-ref-fmt-e">%E</a>, |
| <a href="#tools-cifsim-output-print-ref-fmt-f">%f</a>, |
| <a href="#tools-cifsim-output-print-ref-fmt-g">%g</a>, or |
| <a href="#tools-cifsim-output-print-ref-fmt-g">%G</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-print-ref-fmt-escaping">Escaping and quoting</h8> |
| <div class="paragraph"> |
| <p>Double quote terminate string literals, and thus also a format pattern, as |
| format patterns are string literals. It is therefore not possible to include |
| a double quote in the text of a format pattern without escaping it. That is, |
| use <code>\"</code> inside a format pattern to include a single double quote. There are |
| other escape sequences as well. Use <code>\\</code> to include a single backslash |
| (<code>\</code>), <code>\n</code> to include a single new line (to continue on a new line), and |
| <code>\t</code> to include a tab character (for alignment).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Format specifiers start with a percentage character (<code>%</code>). If a percentage |
| character is to be included as a percentage character instead of being |
| interpreted as a format specifier, it needs to be escaped as well. That is, |
| to include a percentage character as a percentage character, use <code>%%</code> in |
| the format pattern.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the format pattern <code>"a\"b\nc\td\\e%%f"</code> results in the |
| following text:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>a"b |
| c d\e%f</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-unused-values">Unused values</h8> |
| <div class="paragraph"> |
| <p>The format pattern is automatically checked for unused values. That is, if a |
| value is not used in the format pattern, there is no use in specifying it, and |
| a warning will indicate this.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-svgviz-chapter-index">SVG visualizer</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The CIF simulator supports several forms of <a href="#tools-cifsim-output-chapter-index">output</a>. |
| By default, simulation results, such as the |
| current <a href="#tools-cifsim-traces-state">state</a>, are printed to the console. |
| While this provides useful information, it is not easy to decipher the precise |
| state of a (sub-)system. Also, it does not give a graphical overview of the |
| current state of the system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The simulator however, also supports <em>SVG visualization</em>, which allows the user |
| to make an image of the system, and have that image be updated by the simulator |
| during simulation, based on the current state of the system. This allows the |
| user to see changes in the state of the system, in a graphical representation |
| of that system. This makes it much easier to get a global overview of the |
| system during simulation. Since the user makes the image, the representation |
| directly corresponds to the way the user sees the system.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Documentation</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-first-example">First example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svg">Scalable Vector Graphics (SVG)</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-simulation">Simulation of SVG visualizations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-debugging">Debugging SVG visualizations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-viewer">SVG viewer and visualizer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-svgviz-examples" class="paragraph"> |
| <p><strong>Examples</strong></p> |
| </div> |
| <div class="paragraph"> |
| <p>Below is a list of available examples of SVG visualizations, which show some |
| often used SVG attributes, as well as some tips and tricks on how to handle |
| common challenges. The following examples are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-sun-moon">Sun/moon example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-walk">Walk example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-rate">Rate example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-workstation">Workstation example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-tank">Tank example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-lamps">Lamps example</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-example-buffers-products">Buffers/products example</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-first-example">First example</h7> |
| <div class="paragraph"> |
| <p> |
| Before we go into any details about SVG visualization, let’s first look at an |
| example. Here, we use a trivial example, which nonetheless serves several |
| purposes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>It gives a quick overview of what the idea of SVG visualization is all about, |
| and what it looks like.</p> |
| </li> |
| <li> |
| <p>It shows how to use SVG visualization with the CIF simulator.</p> |
| </li> |
| <li> |
| <p>It shows the two alternatives to simulation: via the options dialog, and by |
| using a ToolDef <a href="#tools-scripting-chapter-intro">script</a>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Note that it is not necessary to fully understand what exactly is going on, or |
| how it works. Those details should become clear after reading the remaining |
| pages of the documentation.</p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-creating-the-cif-model">Creating the CIF model</h8> |
| <div class="paragraph"> |
| <p>In an Eclipse project or directory, create a new CIF file named <code>lamp.cif</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "lamp.svg"; |
| |
| automaton lamp: |
| cont t der 1.0; |
| |
| location Off: |
| initial; |
| edge when t >= 1.0 do t := 0.0 goto On; |
| |
| location On: |
| edge when t >= 2.0 do t := 0.0 goto Off; |
| |
| svgout id "lamp" attr "fill" value if Off: "gray" else "yellow" end; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This file describes not only the behavior of the lamp using a CIF automaton, |
| but also contains a <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declaration</a>, which specifies the connection between |
| the behavioral CIF specification and the SVG image.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-creating-the-svg-image">Creating the SVG image</h8> |
| <div class="paragraph"> |
| <p>Next, we’ll create an <a href="#tools-cifsim-output-svgviz-chapter-svg">SVG</a> image. |
| Start |
| <a href="http://inkscape.org/">Inkscape</a>, |
| Select |
| <b class="menuref">Document Properties…​</b> |
| from the |
| <b class="menuref">File</b> |
| menu, to open the |
| <b class="menuref">Document Properties</b> |
| window. On the |
| <b class="menuref">Page</b> |
| tab, set the |
| <b class="menuref">Units</b> |
| to |
| <b class="menuref">px</b>, |
| the |
| <b class="menuref">Width</b> |
| to <code>75.00</code>, and |
| the height to <code>100.00</code>. It is recommended to always |
| <a href="#tools-cifsim-output-svgviz-inkscape-size">set the size</a> of the image, |
| before adding any shapes or text labels.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Next, select the circle tool, by clicking on the circle in the <em>Toolbox</em> on the |
| left side of the application. Draw a circle on the canvas. It should look |
| something like this:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/lamp/lamp_inkscape.png" alt="lamp inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Right click the circle and choose |
| <b class="menuref">Object Properties</b>. |
| The |
| <b class="menuref">Object Properties</b> |
| window will appear. Change the |
| <b class="menuref">Id</b> |
| of |
| the circle to <code>lamp</code> and click the |
| <b class="button">Set</b> |
| button. Save the image |
| as <code>lamp.svg</code>, in the same directory as the <code>lamp.cif</code> file.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-simulation-and-the-options-dialog">Simulation and the options dialog</h8> |
| <div class="paragraph"> |
| <p>Right click the <code>lamp.cif</code> file and choose |
| <b class="menuref">Simulate CIF specification…​</b> |
| to start the CIF simulator. An |
| options dialog appears. In this case the defaults suffice, so click |
| <b class="button">OK</b> |
| to start the simulation. Initially, the visualization looks as |
| follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/lamp/lamp_sim_off.png" alt="lamp sim off"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Using the |
| <b class="menuref">GUI input</b>, |
| click the button for |
| <b class="button">time delay</b> |
| and then the button for |
| <b class="button">tau</b>. |
| After performing these two |
| transitions, the visualization should look as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/lamp/lamp_sim_on.png" alt="lamp sim on"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>As you can see, the lamp is gray while it is off, and yellow while it is on. |
| Close the |
| <b class="menuref">GUI input</b> |
| to terminate the simulator. You may also close |
| the visualization window.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Now restart the simulator. In the |
| <b class="menuref">Simulator</b> |
| category, set the |
| <a href="#tools-cifsim-solver-chapter-endtime-maxdelay">Simulation end time</a> option to |
| <b class="menuref">Finite end time</b>. |
| You can leave the default value for |
| <b class="menuref">End time</b>. |
| In the |
| <b class="menuref">Input</b> |
| category, set the |
| <a href="#tools-cifsim-input-chapter-index">Input mode</a> option to |
| <b class="menuref">Automatic input mode</b>. |
| In the |
| <b class="menuref">Output</b> |
| category, enable |
| the <a href="#tools-cifsim-output-realtime-framerate">Frame rate</a> option and |
| keep the default frame rate value. Click |
| <b class="menuref">OK</b> |
| to start the simulation |
| again. This time, the simulator automatically chooses transitions. Furthermore, |
| <a href="#tools-cifsim-output-chapter-realtime">real-time simulation</a> is enabled, where |
| the model time is interpreted in seconds, and the visualization is regularly |
| updated. Using these options, SVG visualization essentially turns into an |
| SVG movie of the simulation of a flashing lamp. Simulation will automatically |
| stop after ten seconds, the default simulation end time. Once simulation |
| terminates, you may close the visualization window.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-simulation-using-tooldef">Simulation using ToolDef</h8> |
| <div class="paragraph"> |
| <p>While the option dialog is useful for configuring simulation options, it is |
| often easier to use a <em>ToolDef</em> file to |
| <a href="#tools-scripting-chapter-intro">script</a> the execution of the CIF simulator. |
| Create a new file named <code>lamp.tooldef</code>, in the same directory as the other |
| files, and give it the following content:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim( |
| "lamp.cif", |
| "-t 10", |
| "-i auto", |
| "--frame-rate=20", |
| );</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Don’t forget to save the file. Right-click the <code>lamp.tooldef</code> file and |
| choose |
| <b class="menuref">Execute ToolDef</b> |
| to execute the ToolDef script. This script |
| uses the exact same options as we manually configured in the option dialog, in |
| the previous section.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-svg">Scalable Vector Graphics (SVG)</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The SVG visualization feature uses Scalable Vector Graphics (SVG) images. |
| <a href="http://www.w3.org/TR/SVG11/">SVG</a> |
| is a widely-deployed royalty-free standard |
| for two-dimensional vector graphics, developed by the |
| <a href="http://www.w3.org/">World Wide Web Consortium</a> |
| (W3C). SVG images consist of |
| three types of objects: vector graphic shapes (rectangles, circles, etc.), |
| raster images, and text. The benefit of vector images formats over raster image |
| formats, is that raster images are created with a fixed size, while vector |
| images contain a description of the image and can be rendered at any size |
| without loss of quality.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-svgviz-svg-svg11" class="paragraph"> |
| <p>Multiple versions of the SVG standard exist. The CIF simulator uses the |
| free and open source |
| <a href="http://xmlgraphics.apache.org/batik/">Apache Batik SVG Toolkit</a> |
| to render SVG images. Batik supports |
| version 1.1 of the SVG specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| SVG image files are stored in an |
| <a href="http://en.wikipedia.org/wiki/XML">XML</a>-based file format. This means that |
| they can be edited with any text editor. However, it is often more convenient |
| to edit them with a drawing program that supports vector graphics, such as |
| <a href="http://www.adobe.com/products/illustrator.html">Adobe Illustrator</a> |
| or |
| <a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a>. Most modern web |
| browsers also support SVG images.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since SVG images are essentially XML files, we get all the benefits of XML |
| for free. One of those benefits is that XML files represent tree structures, |
| which can be easily manipulated by applications. This is essential for the CIF |
| simulator. During initialization, the CIF simulator loads the SVG image |
| file that the user provided, and subsequently has access to the XML tree. |
| It then uses the aforementioned Batik toolkit to draw the SVG image |
| represented by the XML tree. Once the simulator starts taking transitions and |
| updates its <a href="#tools-cifsim-traces-state">state</a>, it can use the |
| information from the state to modify the XML tree. Changes to the XML tree then |
| result in an updated SVG image, the next time the image is rendered again.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-svgviz-svg-id" class="paragraph"> |
| <p>In order to be able to modify particular objects (shapes, text labels, etc.) of |
| the SVG image, the simulator should be able to identify the objects that make |
| up the image. Here we once again reap the benefits of XML. All nodes (called |
| elements) in the XML tree can have an <code>id</code> attribute that specifies the |
| id (also called name or identity) of the element. As such, all SVG objects can |
| be identified using their unique id. The |
| <a href="#tools-cifsim-output-svgviz-svgout-id">SVG element id</a> section of the |
| <a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a> page further explains the |
| use of SVG element ids.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| The website of Jakob Jenkov has a very nice |
| <a href="http://tutorials.jenkov.com/svg">SVG Tutorial</a>.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</h7> |
| <div class="paragraph"> |
| <p> |
| |
| SVG images can best be edited with a drawing program that supports vector |
| graphics. One such program is |
| <a href="http://inkscape.org/">Inkscape</a>, |
| a free and |
| open source vector graphics editor that uses SVG as its native file format, and |
| is available for many platforms, including Microsoft Windows, Mac OS X, and |
| Linux. In this documentation, we’ll use Inkscape to create and edit SVG images.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is beyond the scope of this document to explain how Inkscape works. For |
| that, see the |
| <a href="http://inkscape.org/">Inkscape website</a>. |
| Here is a screenshot of the Inkscape interface:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/inkscape/inkscape.png" alt="inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-changing-ids">Changing ids</h8> |
| <div class="paragraph"> |
| <p>As described on the <a href="#tools-cifsim-output-svgviz-chapter-svg">page about SVG</a>, |
| every SVG object has an id. To change the id of an object in Inkscape, right |
| click on the object, and choose |
| <b class="menuref">Object Properties</b>. |
| The |
| <b class="menuref">Object Properties</b> |
| window will appear, which looks like this:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/inkscape/inkscape_props_xml.png" alt="inkscape props xml"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this window, you can change the object’s id, by entering a new id in the |
| <b class="menuref">Id</b> |
| field, and clicking the |
| <b class="button">Set</b> |
| button.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-xml-editor">XML editor</h8> |
| <div class="paragraph"> |
| <p>Inkscape also features an XML editor, that can be used to view and edit the |
| underlying XML representation of the SVG image. The screenshot above also shows |
| Inkscape’s |
| <b class="menuref">XML Editor</b> |
| window, which can be opened via the |
| <b class="menuref">XML Editor…​</b> |
| item in the |
| <b class="menuref">Edit</b> |
| menu. The XML editor |
| can be useful to find out the exact structure of the XML tree, and to see the |
| precise definitions that were used to represent the objects that you created |
| on Inkscape’s canvas.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-inkscape-size">Document size</h8> |
| <div class="paragraph"> |
| <p>It is recommended to always set the correct size of the image, before adding |
| any shapes or text labels. To do this, select |
| <b class="menuref">Document Properties…​</b> |
| from the |
| <b class="menuref">File</b> |
| menu, to open the |
| <b class="menuref">Document Properties</b> |
| window. On the |
| <b class="menuref">Page</b> |
| tab, we |
| recommend to set the |
| <b class="menuref">Units</b> |
| to |
| <b class="menuref">px</b>. |
| You can then enter |
| the |
| <b class="menuref">Width</b> |
| and |
| <b class="menuref">Height</b> |
| of the image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, Inkscape always adds a layer to new images. When changing the size |
| of the image as described above, this layer gets a <code>transform</code> attribute |
| that can cause all kinds of trouble later on. There are several ways to get |
| rid of this <code>transform</code> attribute of the layer:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Select |
| <b class="menuref">Layers…​</b> |
| from the |
| <b class="menuref">Layer</b> |
| menu to show the |
| <b class="menuref">Layers</b> |
| panel. In that panel, select |
| <b class="menuref">Layer 1</b> |
| by |
| clicking on it. Then click the |
| <b class="menuref">Delete the current layer</b> |
| button |
| to remove the selected layer.</p> |
| </li> |
| <li> |
| <p>Use the |
| <b class="menuref">XML Editor</b> |
| to select the layer |
| (<code><svg:g id="layer1"</code>…​ node). Then click the |
| <b class="menuref">Delete node</b> |
| button at the top of the |
| <b class="menuref">XML Editor</b> |
| window to remove the layer. |
| Alternatively, after selecting the layer, press the <kbd>Delete</kbd> key on the |
| keyboard to delete the selected layer.</p> |
| </li> |
| <li> |
| <p>Use the |
| <b class="menuref">XML Editor</b> |
| to select the layer |
| (<code><svg:g id="layer1"</code>…​ node). Then, on the right, select the |
| <code>transform</code> attribute by clicking on it. Then click the |
| <b class="menuref">Delete attribute</b> |
| button at the top of the |
| <b class="menuref">XML Editor</b> |
| window to remove the attribute.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The first two approaches remove the layer, the third approach keeps the layer |
| and only removes the <code>transform</code> attribute.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Alternatively, there is also a way to avoid the <code>transform</code> attribute from |
| being added in the first place. Instead of using the |
| <b class="menuref">Document Properties</b> |
| window to change the size of the image, do |
| the following:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Use the |
| <b class="menuref">XML Editor</b> |
| to select the entire image |
| (<code><svg:svg</code>…​ node).</p> |
| </li> |
| <li> |
| <p>Select the <code>width</code> attribute on the right, by clicking on it.</p> |
| </li> |
| <li> |
| <p>Change the value in the text area at the lower right corner of the window.</p> |
| </li> |
| <li> |
| <p>Click the |
| <b class="menuref">Set</b> |
| button to save the new width value. Alternatively, |
| after typing the new value, press <span class="keyseq"><kbd>Ctrl</kbd>+<kbd>ENTER</kbd></span> to save the |
| new width value.</p> |
| </li> |
| <li> |
| <p>Repeat for the <code>height</code> attribute.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-coordinate-systems">Coordinate systems</h8> |
| <div class="paragraph"> |
| <p>The coordinate system used by Inkscape uses the lower left |
| corner of the canvas as origin, while the underlying SVG representation uses |
| the upper left corner of the canvas as origin. Also, Inkscape uses x and y |
| coordinates of objects relative to the outside of their border (called <em>stroke</em> |
| in Inkscape), while SVG uses x and y coordinates of objects relative to the |
| middle of their border. These are two most commonly encountered differences |
| between Inkscape and SVG. See the <a href="#tools-cifsim-output-svgviz-chapter-example-tank">tank example</a> |
| for some tips and tricks regarding the difference in coordinate systems.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-inkscape-textarea">Text areas</h8> |
| <div class="paragraph"> |
| <p>When using the Inkscape text tool, select the tool, and left click once on the |
| canvas to add a text label. Once you added it, start typing text.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Inkscape also allows you to select the text tool, left click anywhere on the |
| canvas, drag the mouse pointer to another position, and only then release the |
| left mouse button. This creates a text area, where text is automatically |
| wrapped to multiple lines, so that it stays within the bounds of the text area. |
| This feature uses SVG <code>flowRoot</code> elements. These elements are defined in |
| version 1.2 of the SVG standard, which is currently still a working draft. |
| These elements are <em>not</em> supported by the CIF simulator, which only supports |
| version 1.1 of the SVG standard.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using an SVG image with a <code>flowRoot</code> or other unsupported SVG feature, |
| results in the following error when the SVG file is |
| <a href="#tools-cifsim-output-svgviz-chapter-viewer">opened</a> in Eclipse:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">ERROR: SVG image file "some_image.svg" is not an SVG file, is an invalid SVG file, or contains unsupported SVG features. |
| CAUSE: invalid.element</code></pre> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The connection between the <a href="#tools-cifsim-traces-state">state</a> of the CIF |
| specification and the SVG image can be specified by using CIF/SVG declarations |
| (sometimes also called SVG declarations, for simplicity). Such declarations can |
| be specified directly in the CIF specification. CIF/SVG declarations are an |
| extension to the CIF language, and can only be used to couple the model to the |
| image. They don’t influence the behavior of the model itself.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF <a href="#tools-chapter-text-editor">text editor</a> provides full integration for |
| the CIF/SVG declarations extension, complete with syntax highlighting, |
| background validation, etc.</p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-declarations">Declarations</h8> |
| <div class="paragraph"> |
| <p>The following types of CIF/SVG declarations are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declarations</a>: |
| Specifies which SVG image file to use.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declaration</a>: |
| Specifies that a part of the SVG image should be copied.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declaration</a>: |
| Specifies that a part of the SVG image should be moved.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a>: |
| Specifies how to update a certain property of an element of the SVG image.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-svg-chapter-svgin">CIF/SVG input mappings</a>: |
| Specifies how interaction with the SVG image affects simulation.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-svgfile">SVG file declarations</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| Before any other CIF/SVG declarations can be specified, you need to indicate to |
| which SVG image (file) they apply, using an SVG file declaration. A typical SVG |
| file declaration looks like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "some_file.svg";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG files are declared based on their file names. If possible, it is |
| recommended to use the same file name for the CIF specification and for the |
| SVG image, only with different file extensions. This way, it is easy to see |
| which images goes with which CIF specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-paths-2">Paths</h8> |
| <div class="paragraph"> |
| <p>It is possible to use relative (or absolute) paths for the SVG files. For |
| instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "svg_files/some_file.svg"; |
| svgfile "../images/some_file.svg";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For the first SVG file declaration, the tools will look for an <code>svg_files</code> |
| directory in the same directory as the CIF file, and for a <code>some_file.svg</code> |
| file in that <code>svg_files</code> directory. For the second SVG file declaration, the |
| tools will look for an <code>images</code> directory in the parent directory of the |
| directory that contains the CIF file, and for a <code>some_file.svg</code> file in that |
| <code>images</code> directory.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Files and directories are separated using slashes (<code>/</code>), regardless of the |
| used operating system. It is also allowed to use backslashes (<code>\</code>), which are |
| more common on Microsoft Windows operating systems, but they need to be escaped |
| as <code>\\</code> for this to work, making it easier to use slashes (<code>/</code>) instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-scoping-3">Scoping</h8> |
| <div class="paragraph"> |
| <p>CIF/SVG file declarations (and all 'other' CIF/SVG declarations) can be |
| specified in all components. That is, they can be specified in the top level |
| scope of the specification, in groups and group definitions, as well as in |
| automata and automaton definitions. An SVG file declaration that is specified |
| in a certain scope applies to that scope, as well as all child scopes that |
| don’t have an SVG file declaration of their own. Additionally, all 'other' |
| CIF/SVG declarations (such as |
| <a href="#tools-cifsim-output-svgviz-chapter-svgout">SVG output mappings</a>) may include |
| a local SVG file declaration, that only applies to that specific CIF/SVG |
| declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "file1.svg"; |
| |
| svgout id "a" attr "b" value 5; |
| |
| svgout id "c" attr "d" value 6 file "file2.svg"; |
| |
| group g: |
| svgfile "file3.svg"; |
| |
| svgout id "e" attr "f" value 7; |
| |
| svgout id "g" attr "h" value 8; |
| |
| svgout id "i" attr "j" value 9 file "file4.svg"; |
| |
| group h: |
| svgfile "file5.svg"; |
| end |
| |
| group i: |
| svgout id "k" attr "l" value 10; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The mapping for the SVG element with id <code>a</code> is declared in the top level |
| scope of the specification, and does not have a local SVG file declaration. |
| As such, the SVG file declaration from the top level scope (<code>file1.svg</code>) |
| applies to it. The mapping for the SVG element with id <code>b</code> is declared in |
| the same scope, but has a local SVG file declaration (<code>file2.svg</code>). The local |
| SVG file declaration (<code>file2.svg</code>) overrides the SVG file declaration from |
| the top level scope (<code>file1.svg</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g</code> also has an SVG file declaration (<code>file3.svg</code>). This overrides |
| the SVG file declaration from the top level scope (<code>file1.svg</code>). The SVG |
| file declaration from group <code>g</code> (<code>file3.svg</code>) thus applies to the |
| mappings for ids <code>e</code> and <code>g</code>, as they are declared in the same scope, and |
| don’t have local SVG file declarations. The mapping for SVG element id <code>i</code> |
| has a local SVG file declaration (<code>file4.svg</code>), and as such the SVG file |
| declaration from group <code>g</code> (<code>file3.svg</code>) does not apply to it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG file declaration (<code>file5.svg</code>) from group <code>g.h</code> does not apply to |
| any mappings. The simulator will show the image, but the image will not change |
| during simulation. A warning is printed to the console, to indicate the |
| potential problem.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g.i</code> does not have an SVG file declaration, so the SVG file |
| declaration (<code>file3.svg</code>) from group <code>g</code> (the parent scope of group |
| <code>g.i</code>) applies to the mapping for SVG element id <code>k</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also the <a href="#tools-cif2cif-chapter-svg-file-into-decls">Push SVG file declarations into other CIF/SVG declarations</a> CIF to CIF |
| transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-completeness-and-uniqueness">Completeness and uniqueness</h8> |
| <div class="paragraph"> |
| <p>Every CIF/SVG declaration that is not itself an SVG file declaration, requires |
| an SVG file declaration, in its scope, in one of its ancestor scopes, or |
| locally in that CIF/SVG declaration itself.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In each scope, there may be at most one SVG file declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In every scope (or component), in principle at most one SVG file declaration |
| may be specified. The exception is that for a single scope, specified in |
| multiple CIF files (when imports are used), if the SVG file declarations |
| refer to the same image file, they are merged. If however the two CIF files |
| refer to different image files, this is still considered an error. It is also |
| considered an error if two SVG file declarations are present in a single scope, |
| in a single file, regardless of whether they refer to the same image file or |
| not. In the end, after processing imports, for every scope there must be a |
| unique SVG file declaration, if one is declared at all.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the same SVG image file is specified multiple times, in different SVG file |
| declarations, this is detected by the simulator, and the image will only be |
| shown once. For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id "..." attr "..." value 5 file "some_file.svg"; |
| |
| svgout id "..." attr "..." value 6 file "some_file.svg";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Even though both output mappings specify an SVG file locally, they use the same |
| file. The SVG image will thus only be shown once, and both mappings apply to |
| the same image.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| For each update of a single attribute of an element in the SVG image, an |
| <em>output mapping</em> is needed. An output mapping essentially defines a connection |
| between the CIF specification and the SVG image, for updating that specific |
| attribute of that specific element.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-simple">A simple output mapping</h8> |
| <div class="paragraph"> |
| <p>Assume we have the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont pos der 1.0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Where variable <code>pos</code> is the position of some object, say a box. Then the |
| following output mapping:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id "box" attr "x" value pos;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Keeps the value of the <code>x</code> attribute of the SVG element with id <code>box</code> equal |
| to the value of continuous variable <code>pos</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-syntax">Syntax</h8> |
| <div class="paragraph"> |
| <p>The general syntax of CIF/SVG output mappings is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id <id> attr <attr> value <value>; |
| svgout id <id> attr <attr> value <value> file <file>; |
| svgout id <id> text value <value>; |
| svgout id <id> text value <value> file <file>;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>svgout</code> keyword is followed by a specification of an SVG element |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a>. Every output mapping must |
| <a href="#tools-cifsim-output-svgviz-svgout-id">specify the id</a> of an SVG |
| element, and an SVG element with that id must exist in the SVG image. The |
| <code>id</code> indicates the element for which an attribute or text is to be updated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>id</code> is followed by a specification of what part of the SVG element is to |
| updated. That is, either an |
| <a href="#tools-cifsim-output-svgviz-svgout-attr">attribute</a> or |
| <a href="#tools-cifsim-output-svgviz-svgout-text">text</a> (label) is updated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>After that, the <a href="#tools-cifsim-output-svgviz-svgout-value">value</a> of the |
| attribute or text (label) is specified.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the syntax examples above, we see that it is also allowed to declare an |
| optional local |
| <a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declaration</a>, that only |
| applies to that specific output declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-id">SVG element id</h8> |
| <div class="paragraph"> |
| <p>Every output mapping needs to specify the |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a> of the SVG element to update. |
| The id is checked, to make sure an SVG element with that id actually exists in |
| the SVG image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Only valid SVG names may be used as ids. Valid SVG names start with a letter |
| (<code>a</code> to <code>z</code>, <code>A</code> to <code>Z</code>), an underscore (<code>_</code>), or a colon (<code>:</code>), |
| and may be followed by more of the same characters, as well as dashes (<code>-</code>), |
| dots (<code>.</code>), and numbers (<code>0</code> to <code>9</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Ids must be put between double quotes. For instance, to use <code>some-name</code> as |
| id, it must be written as <code>"some-name"</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Instead of using a hard coded SVG element id, it is also allowed to use an |
| expression that when evaluated results in the SVG element id. Such an |
| expression must evaluate to a <code>string</code> typed value, and must be statically |
| evaluable (must not refer to variables that can change value during simulation, |
| etc). For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Hard coded SVG element id. |
| svgout id "box" attr "width" value ...; |
| |
| // Computed SVG element id. |
| const string c = "bo"; |
| svgout id c + "x" attr "width" value ...;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first output mapping applies to the SVG element with the id <code>box</code>. The |
| <code>box</code> id is hard coded into the output mapping. The second |
| output mapping uses the expression <code>c + "x"</code> to specify the SVG element id. |
| Once the expression is evaluated (its value is computed), this results in the |
| <code>string</code> typed value <code>"box"</code>. As such, the second mapping applies to the |
| SVG element with id <code>box</code> as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The expressions may also refer to for instance algebraic parameters of |
| automaton definitions. Since different values can be given to the parameters |
| for each instantiation, this allows the SVG element id to vary for the |
| different instantiations of the automaton definition. This particular usage |
| allows for reuse and scalable solutions. The |
| <a href="#tools-cifsim-output-svgviz-chapter-example-lamps">lamps example</a> and |
| <a href="#tools-cifsim-output-svgviz-chapter-example-workstation">workstation example</a> |
| are good examples of this usage. This usage is often combined with |
| <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declarations</a> and |
| <a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declarations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-attr">SVG attribute name</h8> |
| <div class="paragraph"> |
| <p>Every output mapping needs to specify the name of the attribute of the SVG |
| element to update (or <code>text</code>, see the |
| <a href="#tools-cifsim-output-svgviz-svgout-text">Text labels</a> section). |
| Similarly to specifying ids, attribute names must be valid SVG names. They also |
| need to be put between double quotes. Unlike SVG element ids, it is not |
| possible to use expressions to specify attribute names. That is, only hard |
| coded names can be used to specify attribute names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is not allowed to change the ids of SVG elements, as it could lead to |
| duplicate or missing ids. As such, output mappings for the <code>id</code> attribute |
| (in any casing) are explicitly not supported. Similarly, changing the <code>style</code> |
| attribute (in any casing) using an output mapping is explicitly not supported, |
| to avoid conflicting style changes. See also the |
| <a href="#tools-cifsim-output-svgviz-svgout-svgcss">SVG presentation attributes vs CSS style attributes</a> section for more |
| information about the <code>style</code> attribute.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The supported attributes for an SVG element depend on what kind of element it |
| is. For instance, a <code>rect</code> element can have an <code>x</code> and <code>y</code> position, a |
| <code>width</code> and <code>height</code>, a <code>fill</code> color, etc. A <code>g</code> element (a group) |
| however, does not support those position attributes. It is beyond the scope of |
| this document to go into more detail. The software however, will warn about |
| using attribute names that are not supported according to the SVG standard (to |
| catch simple spelling mistakes), and specifying attributes on elements that |
| don’t support them. Consult the official |
| <a href="http://www.w3.org/TR/SVG11/">SVG specification</a> |
| for further details. The |
| <a href="#tools-cifsim-output-svgviz-examples">examples</a> showcase several |
| commonly used attributes as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-svgcss">SVG presentation attributes vs CSS style attributes</h8> |
| <div class="paragraph"> |
| <p>SVG uses two kinds of attributes: SVG presentation attributes, and CSS style |
| attributes. For instance, in the following partial SVG image:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><rect fill="red" id="rect1" width="25" height="25" x="65" y="5"/> |
| <rect style="fill:red;" id="rect2" width="25" height="25" x="15" y="5"/></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Rectangle <code>rect1</code> uses the SVG presentation attribute <code>fill</code> to specify the |
| fill color the rectangle. Rectangle <code>rect2</code> uses the CSS style attribute |
| <code>fill</code> to specify the fill color the rectangle. The SVG presentation |
| attributes are all direct attributes of the SVG element. CSS style attributes |
| on the other hand, are always part of the SVG presentation attribute <code>style</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p><a href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">CSS</a> |
| stands for |
| <em>Cascading Style Sheets</em>, and it is a style sheet language used |
| for describing the look and formatting of a document. It’s best known for its |
| use in styling web pages written in |
| <a href="https://en.wikipedia.org/wiki/HTML">HTML</a>. |
| Like SVG, CSS is an international |
| standard developed and maintained by the |
| <a href="http://www.w3.org/">World Wide Web Consortium</a> |
| (W3C). SVG reuses the CSS standard for its CSS style |
| attributes. The most commonly used attributes for certain elements are also |
| available in the SVG standard as SVG presentation attributes. Furthermore, SVG |
| adds additional presentation attributes not found in CSS.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If an attribute is specified on an element using both an SVG presentation |
| attribute, and a CSS style attribute, the CSS style attribute usually takes |
| precedence. The output mappings handle all of this automatically and |
| transparently. That is, you just specify the attribute name in the header of |
| the output mapping, and the simulator makes sure the proper attribute is |
| update, regardless of whether it is an SVG presentation attribute, or a CSS |
| style attribute. It is explicitly not supported to change the <code>style</code> |
| attribute directly (using an output mapping), in order to avoid conflicting |
| style changes when other output mappings update CSS style attributes that are |
| part of that same <code>style</code> SVG presentation attribute.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-text">Text labels</h8> |
| <div class="paragraph"> |
| <p>Changing the text of text labels is a special case, as text is not stored in |
| attributes. Consider the following partial SVG image, which contains a text |
| label (created using <a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a>, |
| and with some of the irrelevant details omitted):</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><text x="5" y="5" id="text1" style="font-size:16px;"> |
| <tspan x="5" y="5" id="tspan2"> |
| The actual text. |
| </tspan> |
| </text></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here we see a <code>text</code> element with id <code>text1</code>, which contains a <code>tspan</code> |
| element with id <code>tspan2</code>. The <code>tspan</code> element contains some text. To change |
| the text of this text label, use one of the following mappings:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id "text1" text value ...; |
| |
| svgout id "tspan2" text value ...;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, instead of the <code>attr</code> keyword followed by the name of the attribute, we |
| simply specify the <code>text</code> keyword. We can either use the id of the <code>text</code> |
| element, or the id of the <code>tspan</code> element. More precisely, we can use the id |
| of an element that contains text (such as the <code>tspan</code> element in our |
| example), or an element (such as the <code>text</code> element in our example) that has |
| a single child, which contains text, or an element that has a single child, |
| which has an single child, which contains text, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In practice, it is usually the easiest to use the |
| <b class="menuref">Object Properties</b> |
| dialog of <a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a>, to get the |
| properties of the text label. The |
| <b class="menuref">Id</b> |
| that is then shown, is the id of the <code>text</code> element.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Note that Inkscape can create |
| <a href="#tools-cifsim-output-svgviz-inkscape-textarea">text areas</a> (SVG <code>flowRoot</code> elements), |
| which are not supported by the CIF tooling.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-value">Output mapping value</h8> |
| <div class="paragraph"> |
| <p>In order for an output mapping to be able to update attributes or text labels, |
| it needs a value. The |
| <a href="#tools-cifsim-output-svgviz-svgout-simple">simple output mapping</a> example |
| already showed how |
| a value can be specified. This section further explains the details of the |
| specification of such values.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>value</code> keyword is followed by an expression. This expression may |
| for instance be a literal value, such as <code>1</code>, <code>true</code>, <code>1.0</code>, |
| <code>"some text"</code>, or <code>[1, 2]</code>. At first, it might not seem useful to use a |
| literal as a value for an output mapping, since the mapping will then produce |
| the same value every time it is applied. However, the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-rate">rate example</a> shows why this can in fact be |
| very useful.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The expressions however, may also contain references to variables (discrete, |
| continuous, or algebraic), functions, constants, locations, etc. For instance, |
| we could use the value of a continuous variable and multiply it by two, by |
| using <code>x * 2</code> as expression, assuming that the continuous variable is named |
| <code>x</code>. Since we may refer to the <a href="#tools-cifsim-traces-state">state</a> of |
| the CIF specification, the value of the expression can change as the simulation |
| continues, resulting in different values being mapped to the image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The expressions can also include <code>if</code> expressions, which are particularly |
| powerful in this context. Using <code>if</code> expressions, a different value can be |
| used for several different conditions. See the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-workstation">workstation example</a> for an example of using |
| <code>if</code> expressions in an output mapping.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-quote-escape">Quoting and escaping</h8> |
| <div class="paragraph"> |
| <p>The value expression of an output mapping may be of any type. The result of |
| evaluating the expression is converted to a textual representation that closely |
| resembles the textual syntax of CIF, before using it to set the value of an |
| attribute, or the text of a text label. For string literals this means that the |
| text is escaped, and double quotes are added. If however the result of the |
| expression is a <code>string</code> typed value, then that string is used 'as is' |
| (without quoting, and without escaping). Thus, consider the following examples:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id "..." attr "..." value ["a\"b"]; |
| svgout id "..." attr "..." value "a\"b";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The value of the first output mapping is a list that contains a single string |
| value, while the value of the second output mapping is a string value directly. |
| This results in the following texts being used as values of the attributes:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">["a\"b"] |
| a"b</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>That is, in general string values are quoted and escaped, as is the case for |
| the first example, where the result is a list. However, if the entire result |
| is a string, as is the case with the second example, the string value is used |
| 'as is', without quoting and without escaping.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-whitespace">Whitespace handling</h8> |
| <div class="paragraph"> |
| <p>If the textual result of an output mapping contains a new line character (for |
| instance due to including <code>\n</code> in a string literal or |
| <a href="#tools-cifsim-output-print-ref-fmt-pattern">format pattern</a>), the new |
| line character is ignored by SVG. Furthermore, tabs (<code>\t</code>) are replaced by a |
| single space character. Finally, |
| <a href="http://www.w3.org/TR/SVG/text.html#WhiteSpace">by default</a> |
| consecutive |
| spaces (including tabs) are merged together into a single space, and spaces at |
| the beginning and end of the output of a mapping are discarded by SVG.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This essentially renders <code>\n</code> and <code>\t</code> useless, as the first is ignored, |
| and for the second spaces can be used instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This also means that it is not possible to set multiple lines of text using a |
| single output mapping. This is a fundamental restriction of SVG, not of CIF/SVG |
| output mappings. In order to set multiple lines of text, multiple output |
| mappings are needed, where each mapping sets a different text label (a |
| different line).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Note that if you enter multiple lines of text in |
| <a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a>, this results in a |
| single <code>text</code> element, with multiple <code>tspan</code> child elements. The actual |
| text of such <code>tspan</code> elements can then be updated using an output mapping |
| for each <code>tspan</code> element. The benefit over multiple text labels (multiple |
| <code>text</code> elements with a single <code>tspan</code> child element each) is that the one |
| <code>text</code> element can be moved, making all the <code>tspan</code> child elements |
| automatically move with it. That is, the lines of text are kept together by |
| Inkscape.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-unique">Uniqueness of output mappings</h8> |
| <div class="paragraph"> |
| <p>All output mappings must be unique, per SVG image. That is, no two mappings may |
| use the exact same SVG element id and attribute name. Similarly, no two |
| mappings may update the same text. That is, for the example above, it is not |
| allowed to specify two mappings for the text of the SVG element with id |
| <code>text1</code>. However, since both elements <code>text1</code> and <code>tspan1</code> have the same |
| text, it is also not allowed to specify output mappings for the text of those |
| two elements.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-svgout-appl">Application</h8> |
| <div class="paragraph"> |
| <p>SVG output mappings are applied for <a href="#tools-cifsim-traces-state">states</a> |
| <a href="#tools-cifsim-output-realtime-frames">frames</a>, throughout simulation. |
| Their first application is after |
| <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">copy declarations</a> and |
| <a href="#tools-cifsim-output-svgviz-chapter-svgmove">move declarations</a> declarations |
| have been applied. For more information, see the |
| <a href="#tools-cifsim-output-svgviz-simulation-order">Application order</a> section.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declaration</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| A CIF/SVG copy declaration can be used to create copies of existing graphical |
| elements of an SVG image. This page explains the technical details of such |
| copy declarations. For concrete examples, see the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-lamps">lamps example</a> or the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-buffers-products">buffers/products example</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-example-2">Example</h8> |
| <div class="paragraph"> |
| <p>Consider the following SVG file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <rect style="fill:red;" id="rect" width="100" height="100" x="20" y="20"/> |
| <g id="grp"> |
| <rect style="fill:green;" id="rect2" width="100" height="100" x="50" y="50"/> |
| </g> |
| <rect style="fill:blue;" id="rect3" width="100" height="100" x="80" y="80"/> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It features three rectangles, with ids <code>rect</code>, <code>rect2</code>, and <code>rect3</code>, each |
| with the same size. They have different <code>fill</code> colors and positions. The |
| second rectangle is enclosed in a group with id <code>grp</code>. Also consider the |
| following CIF file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "svgcopy.svg"; |
| |
| svgcopy id "rect" pre "a"; |
| svgcopy id "grp" post "b"; |
| svgcopy id "rect3" pre "_" post "x";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The effect of the copy declarations on the SVG image is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <rect style="fill:red;" id="arect" width="100" height="100" x="20" y="20"/> |
| <rect style="fill:red;" id="rect" width="100" height="100" x="20" y="20"/> |
| <g id="grpb"> |
| <rect style="fill:green;" id="rect2b" width="100" height="100" x="50" y="50"/> |
| </g> |
| <g id="grp"> |
| <rect style="fill:green;" id="rect2" width="100" height="100" x="50" y="50"/> |
| </g> |
| <rect style="fill:blue;" id="_rect3x" width="100" height="100" x="80" y="80"/> |
| <rect style="fill:blue;" id="rect3" width="100" height="100" x="80" y="80"/> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-syntax">Syntax</h8> |
| <div class="paragraph"> |
| <p>The general syntax of CIF/SVG copy declarations is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgcopy id <orig-elem-id> pre <prefix>; |
| |
| svgcopy id <orig-elem-id> post <postfix>; |
| |
| svgcopy id <orig-elem-id> pre <prefix> post <postfix>; |
| |
| svgcopy id <orig-elem-id> pre <prefix> file "...";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>svgcopy</code> keyword is followed by a specification of an SVG element |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a>. Every copy declaration must |
| <a href="#tools-cifsim-output-svgviz-svgout-id">specify the id</a> of an SVG |
| element, and an SVG element with that id must exist in the original SVG image, |
| or must exist after applying one of the other copy declarations of the same |
| CIF specification. The <code>id</code> indicates the element that is to be copied.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The prefix and postfix are both optional, but at least one of them must be |
| specified. The prefix and postfix are used to generate unique ids for the |
| copied elements. The prefix (if any) is prepended to the ids of the copied |
| elements, while the postfix (if any) is appended to the ids of the copied |
| elements. Prefixes (if specified) must be valid SVG name prefixes, which means |
| they must be valid SVG names, just as |
| <a href="#tools-cifsim-output-svgviz-svgout-id">SVG element ids</a>. |
| Similarly, postfixes (if specified) must be valid SVG name postfixes, which |
| means they must be valid SVG names, but may start with dashes (<code>-</code>), dots |
| (<code>.</code>), and numbers (<code>0</code> to <code>9</code>). Similar to |
| <a href="#tools-cifsim-output-svgviz-svgout-id">ids</a>, expressions may be |
| used for both prefixes and postfixes, as long as they result in a <code>string</code> |
| typed value when they’re evaluated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If we look at the rectangles example above, we see that the <code>rect</code> element is |
| copied, and that the <code>id</code> of the copied element is prefixed with <code>a</code>, |
| resulting in <code>arect</code> as <code>id</code> of the copy. Similarly, <code>rect3</code> is prefixed |
| with <code>_</code> and postfixed with <code>x</code> resulting in <code>_rect3x</code> as <code>id</code> of the |
| copy.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>grp</code> element is copied as well, with a <code>b</code> postfix. This results in |
| a copied group with <code>grpb</code> as its <code>id</code>. Group <code>grp</code> also contains the |
| rectangle with id <code>rect2</code>. When an element is copied, all its contents are |
| copied as well. That is, the copy is recursive. This means that the <code>rect2</code> |
| element is copied as well, and that copy is also given a <code>b</code> postfix, |
| resulting in <code>rect2b</code> as its <code>id</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the syntax examples above, we see that it is also allowed to declare a |
| local <a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declaration</a>, that |
| only applies to that specific copy declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-placement">Placement</h8> |
| <div class="paragraph"> |
| <p>The copies are added to the SVG image, as siblings of their originals. That is, |
| the copies are added just before their originals. In the rectangles example |
| above, this means that the <code>arect</code> copy is added just before the <code>rect</code> |
| original, and the <code>grpb</code> copy is added just before the <code>grp</code> original.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The order of the <code>rect</code>, <code>rect2</code>, and <code>rect3</code> rectangles is important, |
| in that it determines their <em>rendering order</em>. Elements that are listed first, |
| get <em>rendered</em> or <em>painted</em> first. Subsequent elements are painted on top of |
| previously painted elements. Thus, the red <code>rect</code> rectangle is painted first, |
| and is partially covered by the green <code>rect2</code> rectangle, which is painted |
| second and is partially covered by the blue <code>rect3</code> rectangle, which is |
| painted third.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By including copies near their originals (as siblings), the copies get a |
| similar rendering order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is not allowed to copy the root element (the element with id <code>root</code> in the |
| rectangles example above), as that would result in two root elements, which is |
| not allowed by the SVG standard.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-uniqueness-3">Uniqueness</h8> |
| <div class="paragraph"> |
| <p>All copied elements (the element that is copied, its children, the children of |
| its children, etc) have their ids pre- and postfixed to create their new ids. |
| These ids must be unique in the SVG image. That is, the new ids must not yet |
| exist in the original SVG image, or have been used for previously copied |
| elements. The unique ids are requires to ensure that we can still uniquely |
| identify all elements by their ids, and we can thus use the ids to uniquely |
| indicate to which elements other CIF/SVG declarations apply.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider once again the rectangles example above:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <rect style="fill:red;" id="rect" width="100" height="100" x="20" y="20"/> |
| <g id="grp"> |
| <rect style="fill:green;" id="rect2" width="100" height="100" x="50" y="50"/> |
| </g> |
| <rect style="fill:blue;" id="rect3" width="100" height="100" x="80" y="80"/> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We add the following copy declaration:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgcopy id "rect" post "2";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This would result in the <code>rect</code> element being copied, and the copy being |
| given a <code>rect2</code> id. However, there is already an element with that id. As |
| such, the copy declaration is illegal.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At least a prefix or a postfix is required for every copy declaration, as |
| otherwise the new ids would be identical to the original ids.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-overlap">Overlap</h8> |
| <div class="paragraph"> |
| <p>Consider the following SVG file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <g id="g"> |
| <rect style="fill:green;" id="r" width="100" height="100" x="50" y="50"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We use the following copy declarations:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgcopy id "g" post "a"; |
| svgcopy id "r" post "b";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Both the <code>g</code> element and the <code>r</code> element are copied. However, the <code>r</code> |
| element is a part of the <code>g</code> element. Therefore, the <code>r</code> element is copied |
| twice, once for the copy of that element itself, and once for the copy of its |
| parent (<code>g</code>). This leads to the following SVG image:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <g id="ga"> |
| <rect style="fill:green;" id="ra" width="100" height="100" x="50" y="50"/> |
| </g> |
| <g id="g"> |
| <rect style="fill:green;" id="rb" width="100" height="100" x="50" y="50"/> |
| <rect style="fill:green;" id="r" width="100" height="100" x="50" y="50"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>However, if we switch the order of the copies, we get:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <g id="ga"> |
| <rect style="fill:green;" id="rba" width="100" height="100" x="50" y="50"/> |
| <rect style="fill:green;" id="ra" width="100" height="100" x="50" y="50"/> |
| </g> |
| <g id="g"> |
| <rect style="fill:green;" id="rb" width="100" height="100" x="50" y="50"/> |
| <rect style="fill:green;" id="r" width="100" height="100" x="50" y="50"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Copying an element twice by copying the element itself (e.g. <code>g</code>), but also |
| copying an element that it contains (e.g. <code>r</code>) is not recommended. As seen |
| above, the outcome depends on the order, and can be very confusing. CIF gives |
| a warning in case such overlapping copies are used. Generally, instead of |
| copying the element twice, what is really wanted, is to copy the copied |
| element. This can be done as follows:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgcopy id "g" post "a"; |
| svgcopy id "ra" post "b";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>And this results in the following SVG file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="250" height="250" id="root" version="1.1"> |
| <g id="ga"> |
| <rect style="fill:green;" id="rab" width="100" height="100" x="50" y="50"/> |
| <rect style="fill:green;" id="ra" width="100" height="100" x="50" y="50"/> |
| </g> |
| <g id="g"> |
| <rect style="fill:green;" id="r" width="100" height="100" x="50" y="50"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>See the <a href="#tools-cifsim-output-svgviz-chapter-example-buffers-products">buffers/products example</a> for a |
| more concrete example of the usefulness of copying copied elements.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Not that overlap is only detected for copying an element and an element that |
| it contains. Copying the same element multiple times is perfectly valid and |
| useful, and does not result in warnings.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-application">Application</h8> |
| <div class="paragraph"> |
| <p>Copy declarations are only applied once, at the beginning of the simulation, |
| before any of the other CIF/SVG declarations have been applied. For more |
| information, see the <a href="#tools-cifsim-output-svgviz-simulation-order">Application order</a> |
| section.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declaration</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| A CIF/SVG move declaration can be used to move parts of an SVG image to a |
| certain position, regardless of transformations applied to the elements that |
| are moved, or any surrounding groups and layers, etc. This page explains the |
| technical details of such move declarations. For a concrete example, see the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-lamps">lamps example</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-example-3">Example</h8> |
| <div class="paragraph"> |
| <p>Consider the following SVG file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="400" height="400" id="root" version="1.1"> |
| <g id="grp1"> |
| <rect style="fill:green;" id="rect1" width="20" height="20" x="5" y="10" |
| transform="translate(15, 20)"/> |
| </g> |
| <g id="grp2" transform="scale(5, 2)"> |
| <rect style="fill:blue;" id="rect2" width="20" height="20" x="5" y="10" |
| transform="translate(15, 20)"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/svgmove/svgmove.png" alt="svgmove"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It features a group <code>grp1</code>, with a green rectangle <code>rect1</code>. It is 20 by 20 |
| pixels in size. Its position is 20 pixels from the left (<code>x</code> is 5, but the |
| horizontal translation is 15 pixels) and 30 pixels from the top (<code>y</code> is 10, |
| but the vertical translation is 20 pixels).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>grp2</code> and rectangle <code>rect2</code> are similar. Rectangle <code>rect2</code> is |
| blue, and group <code>grp2</code> is scaled 5 times horizontally, and 2 times |
| vertically. This means that rectangle <code>rect2</code> is 100 by 40 pixels in size |
| (5 times 20, and 2 times 20). It also means that the position of <code>rect2</code> |
| is 100 pixels from the left (5 times 20) and 60 pixels from the top (2 times |
| 30).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Also consider the following CIF file:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "svgmove.svg"; |
| |
| svgmove id "rect1" to 10, 10; |
| svgmove id "rect2" to 10, 50;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The upper left corner of the bounding box of rectangle <code>rect1</code> is moved to |
| 10 pixels from the left side, and 10 pixels from the top. The upper left corner |
| of the bounding box of rectangle <code>rect2</code> is moved to 10 pixels from the left |
| side, and 50 pixels from the top. The effect of the move declarations on the |
| SVG image is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="400" height="400" id="root" version="1.1"> |
| <g id="grp1"> |
| <rect style="fill:green;" id="rect1" width="20" height="20" x="5" y="10" |
| transform="translate(15, 20) translate(-10.000000,-20.000000)"/> |
| </g> |
| <g id="grp2" transform="scale(5, 2)"> |
| <rect style="fill:blue;" id="rect2" width="20" height="20" x="5" y="10" |
| transform="translate(15, 20) translate(-18.000000,-5.000000)"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/svgmove/svgmove.out.png" alt="svgmove.out"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Note the translations that have been added to the <code>transform</code> attributes of |
| the rectangles. The additional translation for rectangle <code>rect1</code> is -10 in |
| the x direction and -20 in the y direction, as the rectangle has been moved |
| from position (20, 30) to position (10, 10).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Rectangle <code>rect2</code> has been moved from position (100, 60) to position |
| (10, 50). You might have expected a horizontal translation of -90 and a |
| vertical translation of -10. However, its added translation is for -18 pixels |
| horizontally, and -5 pixels vertically. This is because the scaling applies to |
| this translation as well, and 5 * 18 = 90, and 2 * 5 = 10.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The scaling of the surrounding group complicates the calculations for the |
| transformations of its children (<code>rect2</code> in this case). Moving elements to |
| certain positions becomes more and more complicated when the elements |
| themselves have transformations, their parents have transformations, the |
| parents of their parents have transformations, etc. This especially holds for |
| non-translation transformations, such as <code>scale</code>, <code>rotate</code>, etc. The |
| CIF/SVG move declarations make moving easy, by allowing you to specify the |
| target position, regardless of the existence of such transformations.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-syntax-2">Syntax</h8> |
| <div class="paragraph"> |
| <p>The general syntax of CIF/SVG move declarations is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgmove id <id> to <x>, <y>; |
| |
| svgmove id <id> to <x>, <y> file "...";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>svgmove</code> keyword is followed by a specification of an SVG element |
| <a href="#tools-cifsim-output-svgviz-svg-id">id</a>. Every move declaration must |
| <a href="#tools-cifsim-output-svgviz-svgout-id">specify the id</a> of an SVG |
| element, and an SVG element with that id must exist in the SVG image. The |
| <code>id</code> indicates the element that is to be moved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The x and y target coordinates are both mandatory, and indicate the coordinates |
| of the upper left corner of the bounding box of element that is being moved, |
| relative to the upper left corner of the canvas, after the move is completed. |
| Similar to <a href="#tools-cifsim-output-svgviz-svgout-id">ids</a>, |
| expressions may be used for both the x and y coordinates, as long as they |
| result in a <code>int</code> or <code>real</code> typed value when they’re evaluated. That is, |
| the x and y coordinates must be numeric.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the syntax examples above, we see that it is also allowed to declare a |
| local <a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declaration</a>, that |
| only applies to that specific move declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-moving-graphical-elements">Moving graphical elements</h8> |
| <div class="paragraph"> |
| <p>In order for an element to be moved, it must have a graphical representation. |
| Elements that have a graphical representation include rectangles, paths, text |
| labels, groups, etc. However, certain elements don’t have a graphical |
| representation, and thus can not be moved. An example of elements that can not |
| be moved are the <code>tspan</code> sub-elements of <code>text</code> elements. The <code>tspan</code> |
| sub-elements don’t have graphical representations of their own, they are part |
| of the text labels, and only the <code>text</code> elements have graphical |
| representations.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-conflicting-transformations">Conflicting transformations</h8> |
| <div class="paragraph"> |
| <p>The SVG standard allows for powerful |
| <a href="http://www.w3.org/TR/SVG11/coords.html#TransformAttribute">transformations</a>, |
| including the <code>scale</code> and <code>matrix</code> transformations. Now assume we use a |
| <code>scale(0, 0)</code> transformation. Then all coordinates are multiplied by zero, |
| always resulting in zero. As such, the entire image is scaled into zero by |
| zero pixels. In such cases, there is no translation that can be added to an |
| element, that after application of the scaling transformation, moves it to a |
| certain position. Thus, if such conflicting transformations are present, the |
| move can not be accomplished, and the CIF/SVG move declaration is considered |
| illegal. It should be noted however, that such conflicting transformations are |
| rare, and usually indicate an error has been made in those transformations.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-application-2">Application</h8> |
| <div class="paragraph"> |
| <p>Move declarations are only applied once, at the beginning of the simulation, |
| after the <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">copy declarations</a> have |
| been applied. For more information, see the |
| <a href="#tools-cifsim-output-svgviz-simulation-order">Application order</a> section.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-simulation">Simulation of SVG visualizations</h7> |
| <div class="paragraph"> |
| <p> |
| Once a CIF specification with CIF/SVG declarations, and the SVG image or images |
| are available, it is time to start simulating the CIF specification with SVG |
| visualization. This page discusses the following simulation related topics:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-simulation-order">Application order</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-simulation-option">SVG visualization option</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-simulation-demos">Demonstrations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-simulation-order">Application order</h8> |
| <div class="paragraph"> |
| <p>When the simulator is started, the SVG image is loaded. First, the |
| <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declarations</a> are |
| applied, to ensure all elements exist. For copies of copied elements, the |
| former are applied after the latter, to ensure the elements that need to be |
| copied actually exist. Besides that, the copy declarations from a CIF file |
| are applied in the order in which they are specified (after |
| <a href="#tools-cif2cif-chapter-elim-comp-def-inst">elimination of component definition/instantiation</a>). |
| The copy declarations are only applied once.</p> |
| </div> |
| <div class="paragraph"> |
| <p>After the copy declarations, the |
| <a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declarations</a> |
| are applied. The move declarations from a CIF file are applied in the order in |
| which they are specified (after |
| <a href="#tools-cif2cif-chapter-elim-comp-def-inst">elimination of component definition/instantiation</a>). |
| The move declarations are only applied once.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a> are |
| applied after that, for the initial <a href="#tools-cifsim-traces-state">state</a>. |
| After the output mappings have been applied, the resulting SVG image is shown |
| by the simulator. The output mappings are applied again and again, as the state |
| of the CIF model changes.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The output mappings from a CIF file are applied in the order in |
| which they are specified (after |
| <a href="#tools-cif2cif-chapter-elim-comp-def-inst">elimination of component definition/instantiation</a>). |
| Note however, that the order does not matter, as all output mappings are |
| <a href="#tools-cifsim-output-svgviz-svgout-unique">unique</a> and independent of each |
| other.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Each mapping that is applied, results in an update of an attribute or text |
| label. Either the new value is different from the previous value, or the value |
| is updated to the value that was already there. The results of the mappings |
| are cumulative. That is, the first mapping is applied to the original SVG |
| image, the second mapping is applied to the image that resulted from applying |
| the first mapping, the third mapping is applied to the image that resulted |
| from applying the second mapping, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>During simulation, the simulator provides states to the SVG visualizer, which |
| applies the mappings to each of those states, in order to generate |
| <a href="#tools-cifsim-output-realtime-frames">frames</a>. Whenever the |
| mappings are applied, they are all applied, one after the other. Between the |
| application of the individual output mappings, the display is never updated. |
| That is, only after all mappings are applied, is the visualization updated. |
| This assures that the images are in a consistent state when they are rendered.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By changing the <code>width</code> and <code>height</code> attributes of the root <code>svg</code> element |
| of an SVG image, it is possible to change the size of the image, and thus the |
| canvas on which it is displayed during simulation. Changes to these attributes |
| currently only have effect for the initial state. If the size of the image is |
| changed during simulation, such changes are ignored.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-simulation-option">SVG visualization option</h8> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">SVG visualization</b> |
| option |
| (<b class="menuref">Output: SVG visualization</b> |
| category) can be used to disable SVG |
| visualization. By default, the option is enabled, and SVG visualization is used |
| if the CIF file being simulated declares any CIF/SVG declarations. By disabling |
| the option, SVG visualization is disabled, regardless of whether the CIF |
| specification has any CIF/SVG declarations.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-simulation-demos">Demonstrations</h8> |
| <div class="paragraph"> |
| <p>For demonstrations and presentations, it may be useful to record a movie of a |
| simulation with SVG visualization. This way, during the demonstration, there is |
| no need to manually control the simulation input. Furthermore, a prerecorded |
| movie can’t fail to execute, which may be a problem for live demonstrations. |
| Finally, a prerecorded movie doesn’t change, and is not influenced by the |
| <a href="#tools-cifsim-chapter-performance">performance</a> of the computer on which the |
| demonstration is given.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To record a movie of the SVG visualization, screen recording or screen |
| capturing software can be used. For instance:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="http://camstudio.org/">CamStudio</a> |
| for Microsoft Windows.</p> |
| </li> |
| <li> |
| <p><a href="http://recordmydesktop.sourceforge.net/about.php">recordMyDesktop</a> |
| for Linux.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Both these screen recording applications are free and open source.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Ideally a capturing software supports capturing a region of the screen, so |
| that it is for instance possible to only capture the visualization. |
| Furthermore, it may be beneficial to be able to capture the mouse pointer, so |
| that it is clear where interaction takes place, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-undoreset-3">Undo/reset</h8> |
| <div class="paragraph"> |
| <p>By <a href="#tools-cifsim-input-history-reset-undo">undoing</a> one or more transitions, |
| or by <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation, the |
| state may change. The SVG visualizer is automatically updated to reflect such |
| changes.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-debugging">Debugging SVG visualizations</h7> |
| <div class="paragraph"> |
| <p> |
| |
| If an SVG visualization does not behave as you would expect it to behave, there |
| are several ways to debug such problems. The following approaches are |
| available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-debugging-console">Console debugging</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-debugging-saveas">Save as SVG</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-debugging-stacktrace">Stack traces</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-debugging-console">Console debugging</h8> |
| <div class="paragraph"> |
| <p>Console debugging for CIF/SVG declarations can be enabled or disabled by using |
| the |
| <b class="menuref">Debug output</b> |
| option (<b class="menuref">Output</b> |
| category). It is |
| disabled by default. If enabled, it produces debug output to the console, |
| whenever CIF/SVG declarations are applied. Here is an example of what such |
| output looks like:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">SVG output ("some_file.svg") id "a" text: "10.00" |
| SVG output ("some_file.svg") id "b" text: "0.0" |
| SVG output ("some_file.svg") id "c" text: "3.16" |
| SVG output ("some_file.svg") id "n" attr "fill" (CSS attr): "#ff0000" |
| SVG output ("some_file.svg") id "water" attr "height" (SVG attr): "75.0" |
| SVG output ("some_file.svg") id "water" attr "y" (SVG attr): "104.5"</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Each of the output mappings that is applied, results in a line of debugging |
| output. For output mappings that update the value of an attribute, the output |
| indicates whether the attribute is handled as an |
| <a href="#tools-cifsim-output-svgviz-svgout-svgcss">SVG presentation attribute</a> or as a |
| <a href="#tools-cifsim-output-svgviz-svgout-svgcss">CSS style attribute</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The textual representations of the values that are set, are put between double |
| quotes, and their content is not escaped in any way.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Due to the asynchronous nature of the SVG visualizer, the simulator will |
| continue to calculate the next states that are to become a frame, while the SVG |
| visualizer is still applying mappings for previous frames. As such, the debug |
| output and other simulation output are likely to be out of sync and |
| interleaved. To ease debugging, you can enable the |
| <a href="#tools-cifsim-chapter-test-mode">test mode option</a>, which ensures synchronous |
| execution, and thus synchronous output.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the input mappings, whenever an interactive SVG element is clicked, and |
| the corresponding mapping is used to determine the event to take, a line of |
| debug output is produced. Here is an example of what such output looks like:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">SVG input ("some_file.svg") id "button": event "button.u_pushed" |
| Transition: event button.u_pushed</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>From the line of debugging output, it can be seen that the SVG element with id |
| <code>button</code> was clicked, and this resulted in the execution of event |
| <code>button.u_pushed</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Similar debug output is available for the other CIF/SVG declarations:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">SVG copy ("some_file.svg") id "button" post "1". |
| SVG copy ("some_file.svg") id "button" post "2". |
| |
| SVG move ("some_file.svg") id "button1" to 10.0, 10.0. |
| SVG move ("some_file.svg") id "button2" to 30.0, 10.0.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-debugging-saveas">Save as SVG</h8> |
| <div class="paragraph"> |
| <p>During simulation, the SVG visualizer can be used to |
| <a href="#tools-cifsim-output-svgviz-viewer-saveas">save</a> the currently visible image as |
| an SVG image file. This way, the actual XML representation of the SVG image as |
| it is displayed at that time, can be inspected in an XML editor or text editor. |
| This may give insight in the actual effect of the CIF/SVG declarations applied |
| until that moment.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-debugging-stacktrace">Stack traces</h8> |
| <div class="paragraph"> |
| <p>If the application of a CIF/SVG declaration results in a runtime error, a stack |
| trace is printed to the console. This stack trace makes it possible to track |
| the exact origin of the error. Here is an example of such a stack trace for an |
| output mapping:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">ERROR: Simulation resulted in a runtime error. |
| CAUSE: Evaluation of the SVG output mapping ("some_file.svg") for the text of the SVG element with id "txt1" failed for state: time=0.0, x=-1.5265566588595902e-16. |
| CAUSE: Evaluation of SVG output mapping value "sqrt(x)" failed. |
| CAUSE: Invalid operation: sqrt(-1.5265566588595902e-16).</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, we see that simulation resulted in a runtime error. The cause is that |
| the SVG output mapping for the text of the SVG element with id <code>txt1</code> failed. |
| This points to the exact CIF/SVG mapping that failed, and includes the file |
| name of the SVG image file, as the same id may exist in multiple images. It |
| also includes the state at which the error occurred. The stack trace further |
| indicates that evaluation of the value expression failed, and the actual |
| failure was the evaluation of the <code>sqrt</code> standard library function, with a |
| negative argument.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-viewer">SVG viewer and visualizer</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| Our software comes with an SVG viewer for Eclipse. SVG image files can now be |
| opened for viewing within Eclipse. This same viewer is used as a basis for the |
| SVG visualizer used by the CIF simulator.</p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-viewer">SVG viewer</h8> |
| <div class="paragraph"> |
| <p>Opening SVG files in Eclipse results in them being opened by the SVG viewer. |
| The SVG viewer can be used to preview SVG images from within Eclipse.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the SVG viewer can not open an SVG image, for instance because it contains |
| <a href="#tools-cifsim-output-svgviz-svg-svg11">unsupported features</a> such |
| as <a href="#tools-cifsim-output-svgviz-inkscape-textarea">text areas</a>, the SVG |
| viewer will indicate this. Therefore, opening an SVG image in Eclipse can be |
| used to verify that the SVG image can be used for SVG visualization.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-refresh">Refresh</h8> |
| <div class="paragraph"> |
| <p>The SVG viewer does <em>not</em> refresh its display if the image file is changed. To |
| refresh the image, close the image, and open it again.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cifsim-output-svgviz-viewer-saveas">Save as</h8> |
| <div class="paragraph"> |
| <p>The SVG viewer and SVG visualizer can export the currently visible image to |
| several different image formats. To export the image, first make sure that |
| the SVG viewer or SVG visualizer has the focus. Then select |
| <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Save As…​</b></span> to open the |
| <b class="menuref">Save SVG as</b> |
| dialog. Alternatively, right click the SVG image itself, and choose |
| <b class="menuref">Save As…​</b> |
| from the popup menu, to open the |
| <b class="menuref">Save SVG as</b> |
| dialog. In the dialog, specify the file name of the |
| exported image. Click |
| <b class="button">OK</b> |
| to confirm and to actually export the |
| image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following |
| <a href="http://en.wikipedia.org/wiki/Raster_graphics">raster image</a> |
| formats are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Portable_Network_Graphics">Portable Network Graphics</a> |
| (<code>*.png</code>)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/JPEG">JPEG</a> |
| (<code>*.jpg</code>)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Graphics_Interchange_Format">Graphics Interchange Format</a> |
| (<code>*.gif</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The following |
| <a href="http://en.wikipedia.org/wiki/Vector_graphics">vector image</a> |
| formats are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Scalable_Vector_Graphics">Scalable Vector Graphics</a> |
| (<code>*.svg</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The image format that is used to export the image, is derived from the file |
| extension that is used. For each of the supported file formats, the allowed |
| file names (with file extensions) are indicated above (between parentheses).</p> |
| </div> |
| <div class="paragraph"> |
| <p>After the image is exported, the workspace is refreshed to show that new image |
| file, if the image was saved in a project that is visible in the |
| 'Project Explorer' tab or 'Package Explorer' tab.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-sun-moon">Sun/moon example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Grouping of SVG objects.</p> |
| </li> |
| <li> |
| <p>Controlling the visibility of objects based on the current locations of |
| automata.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image">SVG image</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/sun_moon/sun_moon_inkscape.png" alt="sun moon inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The image features a sun and a moon. The sun consists of a circle and several |
| lines. They are grouped together, using the |
| <b class="menuref">Group</b> |
| command from |
| Inkscape’s |
| <b class="menuref">Object</b> |
| menu. The group can also be seen in the XML |
| representation, as an <code>svg:g</code> element, with the actual shapes (paths in this |
| case) as children. We assigned the <code>sun</code> id to the <code>svg:g</code> element, as it |
| represents the entire sun. For clarity we gave the sub-elements ids as well, |
| although that was not necessary, as we won’t directly reference them in the |
| CIF/SVG declarations.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification">CIF specification</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models the sun/moon example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "sun_moon.svg"; |
| |
| automaton sun_moon: |
| cont t der 1.0; |
| |
| location Day: |
| initial; |
| edge when t >= 12.0 do t := 0.0 goto Night; |
| |
| location Night: |
| edge when t >= 12.0 do t := 0.0 goto Day; |
| |
| svgout id "sun" attr "visibility" |
| value if Day: "visible" else "hidden" end; |
| |
| svgout id "moon" attr "visibility" |
| value switch self: |
| case Day: "hidden" |
| case Night: "visible" |
| end; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Initially, it is day (location <code>Day</code>). It is day for 12 hours, after which it |
| becomes night (location <code>Night</code>). After 12 hours, it becomes day again, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There is one mapping to control the visibility of the sun, and one to control |
| the visibility of the moon. Changing the visibility of the <code>svg:g</code> group |
| element with id <code>sun</code> influences the visibility of all its children. This |
| saves us from having to control the visibility of all the individual shapes |
| that together represent the sun.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both mappings map the current location of automaton <code>sun_moon</code> to either |
| <code>"visible"</code> or <code>"hidden"</code>, although they do it in a different methods. The |
| mapping for the sun uses an <code>if</code> expression, which is shorter in syntax, and |
| especially suited for automata with only two locations. The mapping for the |
| moon uses a <code>switch</code> expression over <code>self</code>, which is a way to refer to |
| automaton <code>sun_moon</code>, from inside that automaton itself. The cases list all |
| the possible locations, and map them to the corresponding visibility values. |
| The <code>switch</code> method is a bit more explicit, and becomes more elegant as the |
| automaton has more locations.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-walk">Walk example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The first part of this example shows a person walking on a floor, and features:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Grouping of SVG objects.</p> |
| </li> |
| <li> |
| <p>The position of grouped objects in SVG.</p> |
| </li> |
| <li> |
| <p>Changing the position of grouped objects using an output mapping.</p> |
| </li> |
| <li> |
| <p>Using the <code>scale</code> standard library function.</p> |
| </li> |
| <li> |
| <p>Using <a href="#tools-cifsim-output-print-chapter-tut-fmt">text formatting</a>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The second part of this example shows a person walking around in a room, and |
| features:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Using multiple values in an output mapping.</p> |
| </li> |
| <li> |
| <p>Using multiple format specifiers in a format pattern.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-walking-on-floor">SVG image (walking on floor)</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for the example of a person walking on a floor:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/walk_floor/walk_floor_orig_inkscape.png" alt="walk floor orig inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The image features a floor (gray bar), a person, and a text label. The |
| person consists of some lines and a circle. These shapes are grouped together, |
| using the |
| <b class="menuref">Group</b> |
| command from Inkscape’s |
| <b class="menuref">Object</b> |
| menu. |
| The group can also be seen in the XML representation, as an <code>svg:g</code> element, |
| with the actual shapes (paths in this case) as children. We assigned the |
| <code>person</code> id to the <code>svg:g</code> element, as it represents the entire person. For |
| clarity we gave the sub-elements ids as well, although that was not necessary, |
| as we won’t directly reference them in the CIF/SVG declarations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Note that we moved the person as a whole, to the start of the floor. Since |
| <code>svg:g</code> elements don’t have an <code>x</code> and <code>y</code> attribute in SVG, Inkscape |
| applies a translation to move the group. This is reflected in the XML as a |
| <code>transform</code> attribute, with the <code>translate(-290,-467)</code> value. This |
| indicates that the person was moved 290 pixels to the left, and 467 pixels to |
| the top (as SVG has its origin in the upper left corner of the canvas).</p> |
| </div> |
| <div class="paragraph"> |
| <p>To get rid of this, once the person is at the correct initial position, we |
| can ungroup the <code>person</code> group ( |
| <b class="menuref">Ungroup</b> |
| command from Inkscape’s |
| <b class="menuref">Object</b> |
| menu), and regroup it. By ungrouping the group, the |
| transformation is pushed to the individual elements of the group. The regroup |
| simply adds a new group around the elements, without a translation |
| transformation. The new group is given an automatically generated name, so we |
| need to rename it to <code>person</code>. This ungroup/group trick is often very useful. |
| After this trick, the image looks as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/walk_floor/walk_floor_inkscape.png" alt="walk floor inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The text label is to be used to show the position of the person, as a |
| percentage. The left position is represented as 0%, and the right position is |
| represented as 100%. The id of the text label is <code>pos_txt</code>.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-walking-on-floor">CIF specification (walking on floor)</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models a person walking on a floor:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Behavior. |
| automaton person: |
| cont pos = 0.0; |
| |
| location forward: |
| initial; |
| equation pos' = 1.0; |
| edge when pos >= 5.0 goto backward; |
| |
| location backward: |
| equation pos' = -1.0; |
| edge when pos <= 0.0 goto forward; |
| end |
| |
| // Visualization. |
| svgfile "walk_floor.svg"; |
| |
| // width of the floor - width of the person = movement |
| // 180px - 19px = 161px |
| svgout id "person" attr "transform" |
| value fmt("translate(%s,0)", scale(person.pos, 0, 5, 0, 161)); |
| |
| svgout id "pos_txt" text |
| value fmt("%.1f%%", scale(person.pos, 0, 5, 0, 100));</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>A person starts at position (variable <code>person.pos</code>) zero (value <code>0.0</code>), and |
| initially moves <code>forward</code>. After (s)he has reached position <code>5.0</code>, the |
| movement is reversed. Once the person is back at the start position, the |
| movement repeats itself.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are two mappings, one that controls the horizontal position of the |
| <code>person</code>, and another that controls the text of the text label.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As stated above, the values of variable <code>person.pos</code> are in the range |
| [0 .. 5]. As can be seen from the comments of the CIF model, the width of the |
| floor and person are 180 pixels and 19 pixels respectively. The person can |
| thus move 161 pixels to the right. The output interval of the <code>scale</code> |
| standard library function is thus [0 .. 161]. As the vertical position is |
| fixed, no vertical translation is required. The |
| <a href="#tools-cifsim-output-print-ref-fmt-pattern">format pattern</a> |
| <code>"translate(%s,0)"</code> inserts the scaled value into the horizontal amount of |
| the translation. The formatted output updates the <code>transform</code> attribute, |
| making the person move horizontally.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The text of the text label with id <code>pos_txt</code> is updated using a second |
| mapping. The value of variable <code>person.pos</code> is once again scaled using the |
| <code>scale</code> standard library function. This time the output range is [0 .. 100], |
| to get a percentage. Format pattern <code>"%.1f%%"</code> uses a <code>%.1f</code> format |
| specifier to convert that percentage to a textual value, with a single digit |
| after the decimal point. After the value of the percentage, a percentage |
| character is included in escaped form (<code>%%</code>), to ensure it is not interpreted |
| as a format specifier.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-walking-in-room">SVG image (walking in room)</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for the example of a person walking around in |
| a room:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/walk_room/walk_room_inkscape.png" alt="walk room inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The image features a room (black rectangle) and a person. The person is the |
| same group of elements as in the example of a person walking on a floor. The |
| same group/ungroup trick is used here as well, to make sure the group has no |
| translation transformation.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-walking-in-room">CIF specification (walking in room)</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models a person walking around in a room:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Behavior. |
| automaton person: |
| cont x = 0.0; |
| cont y = 0.0; |
| |
| location right: |
| initial; |
| equation x' = 1.0; |
| equation y' = 0.0; |
| edge when x >= 5.0 goto down; |
| |
| location down: |
| equation x' = 0.0; |
| equation y' = 1.0; |
| edge when y >= 5.0 goto left; |
| |
| location left: |
| equation x' = -1.0; |
| equation y' = 0.0; |
| edge when x <= 0.0 goto up; |
| |
| location up: |
| equation x' = 0.0; |
| equation y' = -1.0; |
| edge when y <= 0.0 goto right; |
| end |
| |
| // Visualization. |
| svgfile "walk_room.svg"; |
| |
| // width of the room - width of the person = horizontal movement |
| // 180px - 19px = 161px |
| // |
| // height of the room - height of the person = vertical movement |
| // 180px - 40x = 140px |
| svgout id "person" attr "transform" |
| value fmt("translate(%s,%s)", scale(person.x, 0, 5, 0, 161), |
| scale(person.y, 0, 5, 0, 140));</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>A person starts at the top left position, and initially moves to the <code>right</code>. |
| Once (s)he reaches the right side, (s)he start to move <code>down</code>, followed by |
| a <code>left</code> and <code>up</code> movement. After the <code>up</code> movement, the person is once |
| again at the top left position, start another walk around the room, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There is only one mapping, which controls both the horizontal and vertical |
| position of the <code>person</code>. The mapping is similar to the example of a person |
| walking on a floor, except that now both the horizontal and vertical movements |
| are included. The mapping uses two scaled values, one for the horizontal |
| movement, and one for the vertical movement. The format pattern includes both |
| values in the output. The first scaled value controls the horizontal movement, |
| while the second scaled value controls the vertical movement.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-rate">Rate example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The use of literal values in output mappings.</p> |
| </li> |
| <li> |
| <p>How it is best to use simple solutions to solve visualization problems.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-2">SVG image</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/rate/rate_inkscape.png" alt="rate inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG image visualizes a machine as a circle. The rate of the machine is |
| visualized as the background of the circle. The higher the rate, the more the |
| circle is filled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Instead of working with complicated clippings or linear gradients, we use a |
| more simple solution here. The black circle has a transparent background |
| (<code>fill</code> attribute set to <code>none</code>). This is the SVG element with id |
| <code>circle</code>. Behind it is the same circle (id <code>circle_bg</code>), but without a |
| border (<code>stroke</code> attribute set to <code>none</code>), and with a green fill color. |
| Between those two circles, is a rectangle (id <code>circle_bg_rect</code>), that at the |
| top is aligned to the top of the circle. By changing the height of the circle, |
| we can now control what part of the green background circle is obscured by the |
| rectangle.</p> |
| </div> |
| <div class="paragraph"> |
| <p>During the actual visualization, we’ll use a white fill color for the |
| rectangle. Since the background is also white, this 'hides' the rectangle, and |
| makes for a partial green background of the circle. Because a white rectangle |
| can not be distinguished from the background, we used a cyan fill color for the |
| rectangle. This makes that we can easily edit the rectangle, and see whether it |
| has the correct initial position, size, etc.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-2">CIF specification</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models the rate example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Behavior. |
| const real MARGIN = 0.01; |
| |
| automaton machine: |
| cont rate der if rate < target_rate: 1.0 |
| else -1.0 |
| end; |
| disc real target_rate = 0.5; |
| disc dist real rate_sampler = uniform(0.0, 1.0); |
| |
| location: |
| initial; |
| edge when rate - MARGIN <= target_rate and target_rate <= rate + MARGIN |
| do (target_rate, rate_sampler) := sample rate_sampler; |
| end |
| |
| // Visualization. |
| svgfile "rate.svg"; |
| |
| svgout id "circle_bg_rect" attr "height" |
| value scale(machine.rate, 0, 1, 58, 0); |
| |
| svgout id "circle_bg_rect" attr "fill" value "white";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This rather artificial machine has a <code>rate</code> at which it produces. The rate |
| is a value in the interval [0 .. 1]. A target rate (variable <code>target_rate</code>) |
| is randomly chosen in the same interval. The rate is automatically adapted to |
| get closer to the target rate. As soon as the rate is close enough to the |
| target rate, a new target rate is randomly selected, using the |
| <code>rate_sampler</code>, which is a continuous uniform stochastic distribution.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first mapping controls the <code>height</code> of the rectangle. The value of |
| variable <code>machine.rate</code> has a value in the interval [0 .. 1]. This interval |
| is mapped to the [58 .. 0] pixels interval. That is, if the rate is 0, the |
| height of the rectangle is 58 pixels, and it completely covers the background |
| of the circle. The circle then appears with a completely white background. If |
| the rate is 1, the height of the rectangle is 0, and a completely green |
| background is shown. For rates in between 0 and 1, the lower part of the |
| background of the circle is green, and the upper part is white.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second mapping sets the <code>fill</code> color of the rectangle to <code>white</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following image shows an example of the visualization of a partial rate:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/rate/rate_partial.png" alt="rate partial"> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-workstation">Workstation example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Basing the width of an object on the value of a clock in one location, and |
| setting it to a fixed value in another location.</p> |
| </li> |
| <li> |
| <p>Changing the fill color of a rectangle based on the current location of an |
| automaton.</p> |
| </li> |
| <li> |
| <p>Updating multiple attributes of an SVG element, using multiple output |
| mappings.</p> |
| </li> |
| <li> |
| <p>Specifying colors in SVG.</p> |
| </li> |
| <li> |
| <p>Improving scalability by making use of the reuse of mappings.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-3">SVG image</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/workstation/workstation_inkscape.png" alt="workstation inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the image, two machines are clearly visible. Each machine has a bar that |
| shows the progress of the machine. Looking at the |
| <b class="menuref">XML Editor</b> |
| window, we can see the bar has a background (box), and a foreground (front) |
| rectangle. The <code>width</code> and <code>fill</code> color of the latter will be updated to |
| reflect the machine’s status.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-3">CIF specification</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models the workstation example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "workstation.svg"; |
| |
| event generate, transfer, exit; |
| |
| m1: Machine(1, 1.0, generate, transfer); |
| m2: Machine(2, 2.5, transfer, exit); |
| |
| automaton def Machine(alg int nr; alg real ptime; event start, done): |
| cont t der 1.0; |
| |
| location idle: |
| initial; |
| edge start do t := 0.0 goto processing; |
| |
| location processing: |
| edge when t >= ptime goto completed; |
| |
| location completed: |
| edge done goto idle; |
| |
| svgout id "m" + <string>nr + "_bar_front" attr "width" |
| value scale(if processing: t else ptime end, 0, ptime, 0, 130); |
| |
| svgout id "m" + <string>nr + "_bar_front" attr "fill" |
| value if idle : "gray" else "dodgerblue" end; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The example models a workstation with two machines. The first machine has a |
| processing time of <code>1.0</code> time units and the second machine has a processing |
| time of <code>2.5</code> time units. Each machine gets products to <code>start</code> processing, |
| processes them, and sends them out as it is <code>done</code>. The first machine gets |
| its input from an infinite generator (event <code>generate</code>). The second machine |
| sends its finished products to an infinite exit buffer (event <code>exit</code>). |
| Products are transported from the first machine to the second machine via a |
| transport system (event <code>transfer</code>). Note that the <code>Machine</code> automaton |
| definition has three locations. In location <code>idle</code> it is waiting for a |
| product to enter the machine (event <code>start</code>). In location <code>processing</code> it |
| processes the product, which takes <code>ptime</code> time units. Finally, in location |
| <code>completed</code> it has completed processing the product, and waits until it can |
| send it as output. After that, the machine is back in the <code>idle</code> location, |
| where it waits for the next product.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Both machines (<code>m1</code> and <code>m2</code>) are instantiations of the same automaton |
| definition (<code>Machine</code>). The definition/instantiation mechanism allows us to |
| specify the behavior of a machine only once, and still have multiple machines. |
| This reuse improves scalability, as well as maintainability. The reuse of the |
| behavior applies to the visualization as well. By declaring the output mappings |
| in the automaton definition, we get mappings for each instantiation of an |
| actual machine.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since each machine has its own graphical representation in the SVG image, the |
| graphical elements for the different machines have different ids as well. |
| However, they only differ in the number that is used. For instance, there is |
| an <code>m1_bar_front</code> rectangle for the first machine, and an <code>m2_bar_front</code> |
| rectangle for the second machine. In order to make sure each machine gets the |
| correct mappings that apply to their own ids, we added an algebraic parameter |
| <code>nr</code> to the definition of <code>Machine</code>, that indicates to the machine which |
| machine it is. We can then use that <code>nr</code> to compute the id. For machine |
| <code>m1</code>, the <code>Machine</code> automaton definition is instantiated with value <code>1</code> |
| for the <code>nr</code> parameter. The <code>"m" + <string>nr + "_bar_front"</code> id expression |
| then evaluates to <code>"m1_bar_front"</code>, and <code>m1_bar_front</code> is used as the id |
| for the output mapping.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first mapping updates the width of the <code>m*_bar_front</code> rectangles to show |
| the progress of the machines. If a machine is actually <code>processing</code>, the |
| value of clock <code>t</code> is used, as that clock indicates how much of the |
| processing has been completed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When a machine is <code>idle</code> (and waiting for a product) or has <code>completed</code> |
| processing (but can not yet push the processed product out of the machine), |
| the progress is either nothing, or everything. In both cases, we choose the |
| full processing time (variable <code>ptime</code>) as the value. The reason to choose |
| this value for the <code>idle</code> location, becomes clear in the next output mapping.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>ptime</code> value is chosen for the <code>completed</code> location to ensure that |
| the rectangle does not get wider than the box (rectangle <code>m*_bar_back</code>). If |
| we would have used the value of clock <code>t</code> in this location as well, then |
| since the value of the clock keeps increasing in that location, the value |
| becomes larger than <code>ptime</code>, and thus the progress bar would be partly |
| outside the box (rectangle <code>m*_bar_back</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The value that is selected for this first mapping, is transformed using the |
| <code>scale</code> standard library function. The function is used to scale the |
| processing time interval [0 .. <code>ptime</code>] to the [0 .. 130] interval, which |
| represents the <code>width</code> of the rectangle in pixels. The upper bound of 130 |
| pixels matches the <code>width</code> of the box (rectangle <code>m*_bar_back</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second mapping updates the <code>fill</code> color (foreground color) of the same |
| SVG element. In the <code>idle</code> location, the color is <code>gray</code>. Since we used the |
| full width in that location (value <code>ptime</code> in the [0 .. <code>ptime</code>] interval), |
| the entire box is then filled by a gray rectangle, indicating that the machine |
| is idle.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the other locations, the <code>fill</code> color is set to <code>dodgerblue</code>. Since the |
| width in pixels is a value in the interval [0 .. 30], part of the box will be |
| blue, and part will be the background color of the box, which is white. In the |
| <code>completed</code> location, the full width is used as well, resulting in a |
| completely blue box, indicating that the machine has a completely processed |
| product, waiting to be released as output.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-colors-in-svg">Colors in SVG</h8> |
| <div class="paragraph"> |
| <p>In the mappings, as described above, we used names to identify colors. SVG |
| however, provides several ways to specify |
| <a href="http://www.w3.org/TR/SVG11/types.html#DataTypeColor">colors</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="http://www.w3.org/TR/SVG11/types.html#ColorKeywords">Named colors</a>, |
| such as <code>red</code>, <code>yellow</code>, <code>lightblue</code> or <code>burlywood</code>.</p> |
| </li> |
| <li> |
| <p>Decimal RGB (red-green-blue) colors, such as <code>rgb(255,0,0)</code> for <code>red</code>, or |
| <code>rgb(255,255,0)</code> for <code>yellow</code>.</p> |
| </li> |
| <li> |
| <p>Hexadecimal RGB (red-green-blue) colors, such as <code>#f00</code> or <code>#ff0000</code> for |
| <code>red</code>, or <code>#ff0</code> or <code>#ffff00</code> for <code>yellow</code>.</p> |
| </li> |
| <li> |
| <p>RGB (red-green-blue) colors in percentages, such as <code>rgb(100%,0%,0%)</code> for |
| <code>red</code>, or <code>rgb(100%,100%,0%)</code> for <code>yellow</code>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Every color can be specified by one of the three RGB color variants. The colors |
| that have a predefined color name, can be specified in four different ways.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-tank">Tank example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Use of the <code>scale</code> standard library function.</p> |
| </li> |
| <li> |
| <p>The difference between the coordinate systems of <a href="#tools-cifsim-output-svgviz-chapter-inkscape">Inkscape</a> |
| and <a href="#tools-cifsim-output-svgviz-chapter-svg">SVG</a>.</p> |
| </li> |
| <li> |
| <p>How inverting the y-axis can reduce the number of output mappings.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-4">SVG image</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/tank/tank_inkscape.png" alt="tank inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The image features a tank (black lines) and the water in the tank (blue |
| rectangle). The water rectangle is selected. At the top of the screenshot, you |
| see the object’s position as Inkscape represents it. It shows <code>15</code> for the |
| <code>x</code> position, and <code>10</code> for the <code>y</code> position. These values are relative to |
| the lower left corner of the canvas. In the |
| <b class="menuref">XML Editor</b> |
| window, you |
| see the position as SVG represents it. It shows <code>15</code> for the <code>x</code> position |
| as well, but <code>30</code> for the <code>y</code> position. These values are relative to the |
| upper left corner of the canvas. Inkscape and SVG use different coordinate |
| systems, where the <code>y</code>-axis is reversed. The CIF/SVG declarations works on |
| SVG images, and thus uses the coordinate system of SVG.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-4">CIF specification</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models the tank example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Behavior. |
| const real CAPACITY = 10.0; |
| const real MAX_LEVEL = 8.0; |
| const real INIT_LEVEL = 5.0; |
| const real MIN_LEVEL = 2.0; |
| |
| automaton tank: |
| cont level = INIT_LEVEL; |
| |
| location open: |
| initial; |
| equation level' = 1.0; |
| edge when level >= MAX_LEVEL goto closed; |
| |
| location closed: |
| equation level' = -1.0; |
| edge when level <= MIN_LEVEL goto open; |
| end |
| |
| // Visualization. |
| svgfile "tank.svg"; |
| |
| svgout id "water" attr "height" value scale(tank.level, 0, CAPACITY, 0, 80);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this specification, we have a tank filled with water. Initially, the |
| <code>level</code> (height) of the water is <code>5.0</code>, and the valve is <code>open</code>. The |
| level linearly increases with a rate of <code>1.0</code> per time unit. Once the level |
| is <code>MAX_LEVEL</code>, we close the valve, and go to the <code>closed</code> location. Here |
| the level linearly decreases until we reach the minimum level (<code>MIN_LEVEL</code>), |
| after which we open the valve again. The level controller keeps the level |
| between the minimum and maximum allowed levels.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There is only one mapping, and it controls the height of the <code>water</code> |
| rectangle. The water level in the model stays between zero and <code>CAPACITY</code>, by |
| definition (as a higher level would overflow). This results in an input |
| interval of [0 .. <code>CAPACITY</code>]. The height of the tank in the SVG image is |
| <code>80</code> pixels. The output interval thus becomes [0 .. 80].</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-simulation-2">Simulation</h8> |
| <div class="paragraph"> |
| <p>When we simulate the tank example using the CIF specification and SVG image |
| as specified above, we immediately observe a problem:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/tank/tank_problem.png" alt="tank problem"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In SVG the origin is in the upper left corner of the canvas. Changing the |
| height of an object results in the top of the object being fixed, and the |
| bottom of the object being closer to or farther away from that top. What we |
| want in this case, is to have the bottom of the object fixed, and the top of |
| the object being closer to or farther away from the top, depending on the |
| height of the object.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-revisited">SVG image (revisited)</h8> |
| <div class="paragraph"> |
| <p>A naive solution would be to add a second output mapping, to correct the |
| vertical position (<code>y</code> attribute) of the <code>water</code> rectangle. This is a valid |
| solution, and it works. There is however a simpler and more elegant solution.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following, updated SVG image:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/tank/tank2_inkscape.png" alt="tank2 inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This SVG image is the same as the original SVG image for this example, but with |
| an inverted <code>y</code>-axis, for the <code>water</code> rectangle. The <code>y</code>-axis was |
| inverted by using the |
| <b class="menuref">Flip Vertical</b> |
| command from Inkscape’s |
| <b class="menuref">Object</b> |
| menu, while the <code>water</code> rectangle was selected. As can be |
| seen in the screenshot, Inkscape corrects for the applied transformation, and |
| still indicates the same <code>x</code> and <code>y</code> coordinates (at the top of the |
| screenshot). In SVG (and thus the |
| <b class="menuref">XML Editor</b> |
| window), we see a new |
| <code>transform</code> attribute, <code>scale(1,-1)</code> as value, which represents the |
| inversion of the <code>y</code>-axis. Also, the bottom of the water (the inverted top of |
| the water) is now <code>90</code> pixels (the inverted <code>-90</code> value of the <code>y</code> |
| attribute) from the top of the image. Using this vertical flip, we now fixated |
| the 'bottom' of the water, and we can thus change the height of the water |
| without having to correct its position. The mappings for this modified SVG |
| image are the same as the original mappings.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-lamps">Lamps example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Scalability of CIF models and SVG visualizations.</p> |
| </li> |
| <li> |
| <p>The use of <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declarations</a>.</p> |
| </li> |
| <li> |
| <p>The use of <a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declarations</a>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-introducing-the-lamps-example">Introducing the lamps example</h8> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">// Behavior. |
| automaton def Lamp(): |
| event toggle; |
| disc bool on = false; |
| |
| location: |
| initial; |
| edge toggle do on := not on; |
| end |
| |
| lamp1: Lamp(); |
| lamp2: Lamp(); |
| |
| // Visualization. |
| svgfile "lamps2.svg"; |
| |
| svgout id "lamp1" attr "fill" value if lamp1.on: "yellow" else "silver" end; |
| svgout id "lamp2" attr "fill" value if lamp2.on: "yellow" else "silver" end; |
| |
| svgout id "lamp1" attr "stroke-width" value if lamp1.on: 5 else 2 end; |
| svgout id "lamp2" attr "stroke-width" value if lamp2.on: 5 else 2 end;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification has two lamps, <code>lamp1</code> and <code>lamp2</code>. Both lamps have |
| identical behavior, and therefore the behavior is only specified once, using |
| automaton definition <code>Lamp</code>. This definition is instantiated two times, once |
| for each of the lamps. A lamp is initially off, can go on, go off again, go on |
| again, etc. The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/lamps/lamps2_inkscape.png" alt="lamps2 inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The visualization shows the two lamps. The first lamp is off, and has a silver |
| background color. The second lamp is on and has a yellow background color. The |
| lamp that is off has a thin border and the lamp that is on has a thicker |
| border. The CIF specification also contains four |
| <a href="#tools-cifsim-output-svgviz-chapter-svgout">CIF/SVG output mappings</a>, two for |
| the background colors of the circles and two for the thickness of the borders |
| (strokes) of the circles.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-visualization-scalability-issues">SVG visualization scalability issues</h8> |
| <div class="paragraph"> |
| <p>The use of the automaton definition allows us to add another lamp by simply |
| adding the following line to the CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">lamp3: Lamp();</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This single line ensures that we have a third lamp, with the corresponding |
| behavior. However, we also need to adapt the SVG image, by adding another |
| circle, and we need to add two more output mappings to the CIF model. In this |
| case, the additional amount of work is manageable. If however our lamp would |
| have been represented in the image by many different graphical elements, |
| adding another lamp would require copying all those graphical elements, and |
| might also lead to adding many more output mappings per lamp.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Furthermore, if we were to decide to change the graphical representation of |
| lamps from a circle to a square, we would have to change the graphical |
| representation of each of the lamps in the image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It should be clear that this approach does not scale very well. Ideally, we |
| would add another lamp by just adding another instantiation of the <code>Lamp</code> |
| definition as we did above, and automatically get another circle in the image, |
| and two more output mappings in the CIF model.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-a-scalable-solution">A scalable solution</h8> |
| <div class="paragraph"> |
| <p>For the behavior of the lamp, we already had a scalable solution, by using the |
| component definition/instantiation mechanism. That same mechanism can be used |
| to make the image and mappings scalable. First, we’ll change the SVG image:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/lamps/lamps3_inkscape.png" alt="lamps3 inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The second lamp has been removed from the image. We only keep one lamp, as a |
| sort of template for all the lamps. Since we want to use the same graphical |
| representation for all lamps, we only want to include it once in the SVG image. |
| This allows us to change the graphical representation of the template, to have |
| all the lamps change appearance at once. The lamp has been moved outside of the |
| visible part of the canvas, and its <code>id</code> has been changed from <code>lamp1</code> to |
| <code>lamp</code>. The reason for these last two changes will become clear once we look |
| at the new CIF model, and especially the new output mappings:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "lamps3.svg"; |
| |
| automaton def Lamp(alg int nr): |
| // Behavior. |
| event toggle; |
| disc bool on = false; |
| |
| location: |
| initial; |
| edge toggle do on := not on; |
| |
| // Visualization. |
| svgcopy id "lamp" post <string>nr; |
| |
| svgmove id "lamp" + <string>nr to 20 + (nr - 1) * 100, 20; |
| |
| svgout id "lamp" + <string>nr attr "fill" |
| value if on: "yellow" else "silver" end; |
| |
| svgout id "lamp" + <string>nr attr "stroke-width" |
| value if on: 5 else 2 end; |
| end |
| |
| lamp1: Lamp(1); |
| lamp2: Lamp(2); |
| lamp3: Lamp(3);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The first change is that the <code>Lamp</code> automaton definition now has a <code>nr</code> |
| parameter, that indicates which lamp it is. Each lamp is given a different |
| number when instantiated. This allows the lamp automata to know their own |
| identity, and use that for the SVG visualization.</p> |
| </div> |
| <div class="paragraph"> |
| <p>We also put the CIF/SVG declarations for the visualization inside the automaton |
| definition. By doing this, we ensure that each instantiation (each lamp) gets |
| their own version of these declarations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF/SVG declarations have changed as well. A |
| <a href="#tools-cifsim-output-svgviz-chapter-svgcopy">CIF/SVG copy declaration</a> has been added. The copy |
| declaration states that the SVG element with id <code>lamp</code> (the circle) should |
| be copied. It also states that the copy should be postfixed with |
| <code><string>nr</code>. That is, for automaton <code>lamp1</code>, the value of the <code>nr</code> |
| parameter is <code>1</code>, and the id is thus postfixed with <code>"1"</code>. In other words, |
| circle <code>lamp</code> is copied, and the copy is given name <code>lamp1</code> (composed |
| from <code>lamp</code> and <code>1</code>). For <code>lamp2</code>, the id of the copied circle is |
| <code>lamp2</code>, etc. For each of the lamps, the copy gets a different name, that is |
| unique within the SVG image. This single copy declaration takes care of the |
| scalability of the SVG image, by ensuring we have exactly as many circles as we |
| have lamps (not counting the template circle <code>lamp</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The copies of the template circle all get exactly the same attributes as the |
| template (except for their <code>id</code> attribute). As such, they are all positioned |
| outside the visible part of the canvas. The easiest way to put them at the |
| correct positions, is to use a |
| <a href="#tools-cifsim-output-svgviz-chapter-svgmove">CIF/SVG move declaration</a>, which |
| is also new compared to the previous CIF model. The move declarations use the |
| ids of the copied circles, so that each move declaration moves the circle for |
| that specific lamp. They are all moved to 20 pixels from the top of the canvas, |
| and '20 + (<code>nr</code> - 1) * 100' pixels from the left side of the canvas. So, the |
| first lamp (<code>nr</code> 1) is moved to (20, 20), the second lamp (<code>nr</code> 2) is moved |
| to (120, 20), and the third lamp (<code>nr</code> 3) is moved to (220, 20). This single |
| move declaration takes care of the scalability of the positions of the lamps, |
| by ensuring we have exactly as many movements as we have lamps. By using the |
| <code>nr</code> parameter, each lamp can easily be moved to their own unique position.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The output mappings for the background color of the circles and thickness of |
| the borders of the circles, are very similar to the output mappings of the |
| first version of the CIF model, though there are a few changes. The mappings |
| use the same method as the move declaration, to construct the ids. Since the |
| mappings are now defined within the automaton definition, they can directly |
| refer to the <code>on</code> variable. This ensures that for each different lamp, the |
| mappings refer to the <code>on</code> variable of that specific lamp. We now have only |
| one output mapping for the background color, and also only one output mapping |
| for the thickness of the border.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By putting the CIF/SVG declarations inside the automaton definition, and by |
| using the copy and move declarations, we now have a scalable solution. We only |
| have one lamp in our SVG image, only one behavioral specification in the CIF |
| model, and only one output mapping per attribute that we want to couple. No |
| matter how many instantiations of the <code>Lamp</code> automaton definition we add, we |
| don’t have to manually change the SVG image or the visualization coupling.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For completeness, take a look at this CIF model after the |
| <a href="#tools-cif2cif-chapter-elim-comp-def-inst">elimination of component definition/instantiation</a>, the |
| <a href="#tools-cif2cif-chapter-elim-alg-vars">elimination of algebraic variables</a>, and |
| the <a href="#tools-cif2cif-chapter-simplify-values">simplification of values</a>.</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton lamp1: |
| event toggle; |
| disc bool on = false; |
| svgcopy id "lamp" post "1"; |
| svgmove id "lamp1" to 20, 20; |
| svgout id "lamp1" attr "fill" value if on: "yellow" else "silver" end; |
| svgout id "lamp1" attr "stroke-width" value if on: 5 else 2 end; |
| location: |
| initial; |
| edge toggle do on := not on; |
| end |
| automaton lamp2: |
| event toggle; |
| disc bool on = false; |
| svgcopy id "lamp" post "2"; |
| svgmove id "lamp2" to 120, 20; |
| svgout id "lamp2" attr "fill" value if on: "yellow" else "silver" end; |
| svgout id "lamp2" attr "stroke-width" value if on: 5 else 2 end; |
| location: |
| initial; |
| edge toggle do on := not on; |
| end |
| automaton lamp3: |
| event toggle; |
| disc bool on = false; |
| svgcopy id "lamp" post "3"; |
| svgmove id "lamp3" to 220, 20; |
| svgout id "lamp3" attr "fill" value if on: "yellow" else "silver" end; |
| svgout id "lamp3" attr "stroke-width" value if on: 5 else 2 end; |
| location: |
| initial; |
| edge toggle do on := not on; |
| end |
| svgfile "lamps3.svg";</code></pre> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-svgviz-chapter-example-buffers-products">Buffers/products example</h7> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This example shows:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Improving hierarchical scalability by making use of the reuse of mappings.</p> |
| </li> |
| <li> |
| <p>Improving hierarchical scalability by making copies of copied elements.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>It is assumed the reader is already familiar with the |
| <a href="#tools-cifsim-output-svgviz-chapter-example-workstation">workstation example</a>.</p> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-svg-image-5">SVG image</h8> |
| <div class="paragraph"> |
| <p>The following SVG image is used for this example:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/buffers_products/buffers_products_inkscape.png" alt="buffers products inkscape"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG image contains a single template for a buffer (large rectangle), with |
| one product (small rectangle). The template is moved outside of the canvas to |
| ensure the template itself is not shown.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG file has the following XML content:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="svg"><?xml version="1.0" encoding="UTF-8" standalone="no"?> |
| <svg xmlns="http://www.w3.org/2000/svg" |
| xmlns:svg="http://www.w3.org/2000/svg" |
| width="220" height="70" id="root" version="1.1"> |
| <g id="buffer"> |
| <rect width="100" height="50" x="-120" y="10" id="background" style="fill:#ff0000"/> |
| <rect width="10" height="30" x="-110" y="20" id="product" style="fill:#8b0000;visibility:hidden;"/> |
| </g> |
| </svg></code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We’ll use CIF to turn this into two buffers with three products each, in a |
| scalable manner. That is, to add a single buffer, we only need one more |
| instantiation, and also to put an additional product in each buffer, we also |
| only need one more instantiation.</p> |
| </div> |
| </div> |
| <div class="sect7"> |
| <h8 id="tools-cif-specification-5">CIF specification</h8> |
| <div class="paragraph"> |
| <p>The following CIF specification models the buffers/products example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "buffers_products.svg"; |
| |
| buffer0: Buffer(0); |
| buffer1: Buffer(1); |
| |
| group def Buffer(alg int nr): |
| svgcopy id "buffer" post <string>nr; |
| |
| svgmove id "buffer" + <string>nr to 10 + nr * 110, 10; |
| |
| product0: Product(nr, 0); |
| product1: Product(nr, 1); |
| product2: Product(nr, 2); |
| end |
| |
| group def Product(alg int bufferNr, productNr): |
| svgcopy id "product" + <string>bufferNr post "_" + <string>productNr; |
| |
| svgout id fmt("product%d_%d", bufferNr, productNr) |
| attr "transform" |
| value fmt("translate(%d,0)", productNr * 20); |
| |
| svgout id fmt("product%d_%d", bufferNr, productNr) |
| attr "visibility" |
| value "visible"; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Two buffers are present (<code>buffer0</code> and <code>buffer1</code>). Both are instances of |
| the <code>Buffer</code> definition, and are provided with their own identity (parameter |
| <code>nr</code>). For each buffer, the <code>buffer</code> element of the image is copied, and |
| the copy is given a unique number. For instance, for instantiation <code>buffer0</code>, |
| <code>nr</code> is <code>0</code>, and thus <code>buffer</code> is copied to <code>buffer0</code>, <code>background</code> |
| is copied to <code>background0</code> and <code>product</code> is copied to <code>product0</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Each buffer is also moved. The first buffer (<code>nr</code> <code>0</code>) gets moved to |
| position (10, 10), while the second (<code>nr</code> <code>1</code>) gets moved to position |
| (120, 10).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Each buffer contains three products, as the <code>Product</code> definition is |
| instantiated three times. The number of the buffer is passed along, as is a |
| unique product number. For the copy of the products, the copy of the product |
| in the copied buffer is copied, and given a unique name using the product |
| number. For <code>buffer0</code>, the copy of the <code>product</code> was already named |
| <code>product0</code>. This already copied element is copied another three times, to |
| <code>product0_0</code> (by the copy declaration in CIF group <code>buffer0.product0</code>), |
| <code>product0_1</code> (by the copy declaration in CIF group <code>buffer0.product1</code>), |
| and <code>product0_2</code> (by the copy declaration in CIF group <code>buffer0.product2</code>). |
| Similarly, three copies are made for <code>buffer1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Unlike the buffers, which are moved to an absolute position using an |
| <code>svgmove</code>, the products are moved relatively, using an <code>svgout</code> for their |
| <code>transform</code> attribute. The first product (<code>product0_0</code>) is not moved, the |
| second product (<code>product0_1</code>) is moved <code>20</code> pixels, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The buffer template was put outside of the canvas to show only the copies and |
| not the template. For the products, which are contained in the buffers, this |
| trick is not possible. So, instead the <code>visibility</code> of the template |
| <code>product</code> was set to <code>hidden</code> in the original SVG image. To show the actual |
| (copied) products, an <code>svgout</code> is used to set the <code>visibility</code> attribute |
| to <code>visible</code>. The template <code>product</code> is not changed, so it remains hidden.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The result of all this hierarchical 2-level structure is the following SVG |
| image:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/svgviz/buffers_products/buffers_products.png" alt="buffers products"> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-trajdata">Trajectory data output</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The trajectory data (values of the variables as time progresses), calculated |
| by the <a href="#tools-cifsim-solver-chapter-index">ode solver</a>, can be written to a |
| file, using the trajectory data output component.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="tools-cifsim-output-trajdata-option" class="paragraph"> |
| <p>Enable the |
| <b class="menuref">Trajectory data</b> |
| option (<b class="menuref">Output: Trajectory data</b> |
| category) to enable writing the trajectory data to a file.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-trajdata-file" class="paragraph"> |
| <p>By default, the file to which to write the trajectory data, is the name of the |
| input specification file, with <code>.trajdata</code> added to it. Using the |
| <b class="menuref">Trajectory data file</b> |
| option (<b class="menuref">Output: Trajectory data</b> |
| category), a different file can be specified. The value of the option is the |
| absolute or relative local file system path to use for the trajectory data |
| file.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-filtering">Filtering</h7> |
| <div class="paragraph"> |
| <p>Variable <code>time</code> is always included in the trajectory data file. The following |
| additional variables (officially 'state objects') are included by default:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The state variables, which includes the discrete variables and the continuous |
| variables.</p> |
| </li> |
| <li> |
| <p>The derivatives of the continuous variables. This does not include the |
| derivative of variable <code>time</code>.</p> |
| </li> |
| <li> |
| <p>The algebraic variables.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only variables of type <code>bool</code>, <code>int</code> (with or without ranges), or <code>real</code> |
| are included.</p> |
| </div> |
| <div id="tools-cifsim-output-trajdata-filters" class="paragraph"> |
| <p>Using the |
| <b class="menuref">Trajectory data filters</b> |
| option |
| (<b class="menuref">Output: Trajectory data</b> |
| category), the state objects can be |
| filtered. The |
| <b class="menuref">Trajectory data filters</b> |
| option only has effect |
| if trajectory data output is enabled, using the |
| <b class="menuref">Trajectory data</b> |
| option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As value for the option, comma separated <em>filters</em> should be supplied. Each |
| filter specifies one or more state objects. The absolute names of the objects |
| are used. That is, for an automaton <code>a</code>, with a variable <code>x</code>, the absolute |
| name of the variable object is <code>a.x</code>. If CIF textual syntax keyword are |
| used as names for events (such as <code>plant</code>), then they must be escaped in |
| <code>.cif</code> files (<code>$plant</code>). For filters however, all escape characters (<code>$</code>) |
| in the names are ignored. The <code>*</code> character can be used as wildcard, to |
| indicate zero or more characters. If a filter doesn’t match any of the state |
| objects of the CIF model (after filtering them for supported types etc), a |
| warning is printed to the console. A warning is also printed if the entire |
| state is filtered out.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, filters include matching state objects. Filters may however be |
| preceded by a <code>-</code> character, turning them into exclusion filters, which |
| exclude matching states objects rather than including them. Filters are |
| processed in the order they are specified, allowing for alternating additions |
| and removals. If a filter does not result in the addition/removal of any state |
| objects to/from the filter result, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>a.*,-a.b*,a.bc*</code> consists of three filters: |
| <code>a.*</code>, <code>-a.b*</code>, and <code>a.bc*</code>. The first filter indicates that state |
| objects whose absolute names start with <code>a.</code> are to be included. The second |
| filter indicates that from those matching state objects, the state objects |
| whose absolute names start with <code>a.b*</code> are to be excluded. To that result, |
| the third filter adds those state objects whose absolute names start with |
| <code>a.bc*</code>. For instance, if a specification contains state objects <code>time</code>, |
| <code>a.a</code>, <code>a.b</code> <code>a.bb</code>, <code>a.bc</code>, <code>a.b.c</code>, <code>a.bc</code>, <code>a.bcc</code>, and |
| <code>a.bcd</code>, the result of the three filters is that the following state objects |
| are displayed: <code>a.a</code>, <code>a.bc</code>, <code>a.bc</code>, <code>a.bcc</code>, and <code>a.bcd</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default option value (filter) is <code>*</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-output">Output</h7> |
| <div class="paragraph"> |
| <p> |
| The variables are sorted alphabetically, based on their absolute names. The |
| only exception is variable <code>time</code>, which is always listed first.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For variables with a boolean type, value <code>false</code> is represented by <code>0</code>, and |
| value <code>true</code> is represented by <code>1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| For each time transition, the trajectories of the variables are printed to the |
| trajectory data file. The first line is a comment, and contains the names of |
| the variables. Each of the subsequent lines contain the values of the variables |
| for a specific value of variable <code>time</code>. The exact times for which the |
| values are printed to the trajectory data file, is determined by the |
| <a href="#tools-cifsim-solver-chapter-basics-int">ODE solver integrator</a>, and can be |
| influenced using the <a href="#tools-cifsim-solver-chapter-options">integration options</a>, |
| as well as the <a href="#tools-cifsim-solver-chapter-options-outstep">fixed output step size</a> option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>An example of a trajectory data file, for a single time transition:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code># time controller.n tank.V tank.V' tank.Qi tank.Qo |
| 0.0 0 10.0 -3.1622776601683795 0.0 3.1622776601683795 |
| 0.08763429266802605 0 9.7247959763441 -3.1184605138343664 0.0 3.1184605138343664 |
| 0.587634292668026 0 8.228065719426915 -2.868460513834366 0.0 2.868460513834366 |
| 1.087634292668026 0 6.8563354625097315 -2.618460513834366 0.0 2.618460513834366 |
| 1.587634292668026 0 5.609605205592543 -2.3684605138343646 0.0 2.3684605138343646 |
| 2.0876342926680262 0 4.487874948675351 -2.1184605138343624 0.0 2.1184605138343624 |
| 2.5876342926680262 0 3.491144691758149 -1.8684605138343569 0.0 1.8684605138343569 |
| 3.0876342926680262 0 2.619414434840913 -1.618460513834339 0.0 1.618460513834339 |
| 3.496128195593086 0 1.9999999999999958 -1.4142135623730936 0.0 1.4142135623730936</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-trajdata-prettify">Prettifying</h7> |
| <div class="paragraph"> |
| <p>To make the output in the trajectory data file easier to read, the output |
| can be <em>prettified</em>. If prettifying is enabled, then after the simulation ends, |
| the trajectory data file is read, prettified, and rewritten. A fixed width is |
| then used for each column (each variable), with a fixed column separation. |
| After prettification, the above trajectory data file looks like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code># time controller.n tank.V tank.V' tank.Qi tank.Qo |
| 0.0 0 10.0 -3.1622776601683795 0.0 3.1622776601683795 |
| 0.08763429266802605 0 9.7247959763441 -3.1184605138343664 0.0 3.1184605138343664 |
| 0.587634292668026 0 8.228065719426915 -2.868460513834366 0.0 2.868460513834366 |
| 1.087634292668026 0 6.8563354625097315 -2.618460513834366 0.0 2.618460513834366 |
| 1.587634292668026 0 5.609605205592543 -2.3684605138343646 0.0 2.3684605138343646 |
| 2.0876342926680262 0 4.487874948675351 -2.1184605138343624 0.0 2.1184605138343624 |
| 2.5876342926680262 0 3.491144691758149 -1.8684605138343569 0.0 1.8684605138343569 |
| 3.0876342926680262 0 2.619414434840913 -1.618460513834339 0.0 1.618460513834339 |
| 3.496128195593086 0 1.9999999999999958 -1.4142135623730936 0.0 1.4142135623730936</code></pre> |
| </div> |
| </div> |
| <div id="tools-cifsim-output-trajdata-sep" class="paragraph"> |
| <p>By default, the trajectory data output is prettified using a column separation |
| of three spaces. This can be changed using the |
| <b class="menuref">Trajectory data separation amount</b> |
| option |
| (<b class="menuref">Output: Trajectory data</b> |
| category). Using this option, |
| prettification can be disabled, or a different number of spaces can be used |
| between the columns.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-undoreset-4">Undo/reset</h7> |
| <div class="paragraph"> |
| <p>It is possible to go back in time, by |
| <a href="#tools-cifsim-input-history-reset-undo">undoing</a> one or more transitions, or |
| by <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation. |
| However, once a time transition is taken, trajectory data is written to the |
| output file. The simulator does not remove data for time points that are then |
| suddenly in the future. If simulation continues after the undo or reset, new |
| data may be written at the end of the trajectory, for the same time points that |
| were already present earlier in the data file. As such, the data contained in |
| the trajectory data file, may no longer be useful after an undo or reset, if |
| simulation continues afterwards.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-plotviz">Plot visualizer</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| For models with variables, especially continuous ones, it may be useful to be |
| able to observe how their values change, as time progresses during simulation. |
| The <em>plot visualizer</em> can be used for that exact purpose. The plot visualizer |
| can create graphical plots, where the x-axis represents the values of variable |
| <code>time</code>, and the y-axis represents values of the variables being plotted. Here |
| is an example screenshot of the visualizer:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/plotviz_sshot.png" alt="plotviz sshot"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="tools-cifsim-output-plotviz-option" class="paragraph"> |
| <p>Plot visualization is disabled by default. It can be enabled using the |
| <b class="menuref">Plot visualization</b> |
| option (<b class="menuref">Output: Plot visualization</b> |
| category).</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-variables">Variables</h7> |
| <div class="paragraph"> |
| <p>The plot visualizer can plot the values of the following variables (officially |
| 'state objects'):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The state variables, which includes the discrete variables and the continuous |
| variables.</p> |
| </li> |
| <li> |
| <p>The derivatives of the continuous variables. This does not include the |
| derivative of variable <code>time</code>.</p> |
| </li> |
| <li> |
| <p>The algebraic variables.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Only variables of type <code>bool</code>, <code>int</code> (with or without ranges), or <code>real</code> |
| can be plotted. For variables with a boolean type, value <code>false</code> is |
| represented by <code>0</code>, and value <code>true</code> is represented by <code>1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-filtering">Filtering</h7> |
| <div class="paragraph"> |
| <p>By default, if plot visualization is enabled, all variables (officially |
| 'state objects') that can be plotted are plotted. The one exception is variable |
| <code>time</code>, which is excluded by default, as it already represents the x-axis. |
| That is, variables are plotted against time. Using the |
| <b class="menuref">Plot visualization filters</b> |
| option |
| (<b class="menuref">Output: Plot visualization</b> |
| category), the state objects can |
| be filtered. The |
| <b class="menuref">Plot visualization filters</b> |
| option only has effect |
| if plot visualization is enabled, using the |
| <b class="menuref">Plot visualization</b> |
| option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As value for the option, comma separated <em>filters</em> should be supplied. Each |
| filter specifies one or more state objects. The absolute names of the objects |
| are used. That is, for an automaton <code>a</code>, with a variable <code>x</code>, the absolute |
| name of the variable object is <code>a.x</code>. If CIF textual syntax keyword are |
| used as names for events (such as <code>plant</code>), then they must be escaped in |
| <code>.cif</code> files (<code>$plant</code>). For filters however, all escape characters (<code>$</code>) |
| in the names are ignored. The <code>*</code> character can be used as wildcard, to |
| indicate zero or more characters. If a filter doesn’t match any of the state |
| objects of the CIF model, a warning is printed to the console. A warning is |
| also printed if the entire state is filtered out.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, filters include matching state objects. Filters may however be |
| preceded by a <code>-</code> character, turning them into exclusion filters, which |
| exclude matching states objects rather than including them. Filters are |
| processed in the order they are specified, allowing for alternating additions |
| and removals. If a filter does not result in the addition/removal of any state |
| objects to/from the filter result, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>a.*,-a.b*,a.bc*</code> consists of three filters: |
| <code>a.*</code>, <code>-a.b*</code>, and <code>a.bc*</code>. The first filter indicates that state |
| objects whose absolute names start with <code>a.</code> are to be included. The second |
| filter indicates that from those matching state objects, the state objects |
| whose absolute names start with <code>a.b*</code> are to be excluded. To that result, |
| the third filter adds those state objects whose absolute names start with |
| <code>a.bc*</code>. For instance, if a specification contains state objects <code>time</code>, |
| <code>a.a</code>, <code>a.b</code> <code>a.bb</code>, <code>a.bc</code>, <code>a.b.c</code>, <code>a.bc</code>, <code>a.bcc</code>, and |
| <code>a.bcd</code>, the result of the three filters is that the following state objects |
| are displayed: <code>a.a</code>, <code>a.bc</code>, <code>a.bc</code>, <code>a.bcc</code>, and <code>a.bcd</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default option value (filter) is <code>*,-time</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-multiple-plot-visualizers">Multiple plot visualizers</h7> |
| <div class="paragraph"> |
| <p>By default, only one visualizer is shown. However, using the |
| <b class="menuref">Plot visualization filters</b> |
| option |
| (<b class="menuref">Output: Plot visualization</b> |
| category), it is possible to specify |
| that multiple visualizers should be used. The option allows for filtering of |
| the state objects, as described above. However, such filters can be separated |
| by semicolons, to specify the filters per visualizer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, consider option value <code>time,a.x;b.y</code>. This results in two |
| plot visualizers. The first one displays state objects <code>time</code> and <code>a.x</code>, |
| while the second one displays state object <code>b.y</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-mode">Plot visualization modes</h7> |
| <div class="paragraph"> |
| <p>There are two plot visualization modes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Live plotting. In this mode, the plots are shown at the start of the |
| simulation, and are continuously updated as new data becomes available during |
| simulation.</p> |
| </li> |
| <li> |
| <p>Postponed plotting. In this mode, the plots are shown after the simulation |
| has <a href="#tools-cifsim-chapter-termination">ended</a>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Which plot visualization mode to use, can be configured using the |
| <b class="menuref">Plot visualization mode</b> |
| option |
| (<b class="menuref">Output: Plot visualization</b> |
| category). Using that option it is |
| possible to explicitly choose one of the modes. By default, an automatic mode |
| is used, which chooses between live and postponed mode, as follows:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3333%;"> |
| <col style="width: 33.3334%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top"><a href="#tools-cifsim-input-chapter-index">Input mode</a> vs <a href="#tools-cifsim-output-chapter-realtime">real-time simulation</a></th> |
| <th class="tableblock halign-left valign-top">Real-time enabled</th> |
| <th class="tableblock halign-left valign-top">Real-time disabled</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-console">Interactive console input mode</a> (pure interactive)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-console">Interactive console input mode</a> (<a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a>)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">postponed</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-gui">Interactive GUI input mode</a> (pure interactive)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-gui">Interactive GUI input mode</a> (<a href="#tools-cifsim-input-chapter-semi-automatic">semi-automatic</a>)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">postponed</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-automatic">Automatic input mode</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">postponed</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-chapter-trace">Trace input mode</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">postponed</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-input-svg-chapter-index">SVG input mode</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">live</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">postponed</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>When doing a non real-time simulation, using a non-interactive input mode leads |
| to as fast as possible simulation, where a lot of data points are calculated in |
| a short amount of time. If live plotting mode is then enabled, this floods the |
| visualizer with so much data that it can’t keep up. The effect is a |
| non-responsive user interface. While the automatic default can thus be |
| overridden using the option, it is generally not recommended.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-range">Plot visualization range</h7> |
| <div class="paragraph"> |
| <p>For simulations that span longer periods of (model) time, there may be too |
| much data to display, for the limited width of the time axis (x-axis). To keep |
| the plot useful, the range of time values to display on the x-axis can be |
| configured using the |
| <b class="menuref">Plot visualization range</b> |
| option |
| (<b class="menuref">Output: Plot visualization</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, only the <code>50</code> most recent time units are displayed. That is, if |
| the current model time is <code>120</code>, then the plot only shows the values of the |
| variables from time <code>70</code> to time <code>120</code>. Using the option, the length of the |
| range can configured to any other positive value. The option can also be used |
| to set the range to infinite, to display the values of the variables during |
| the entire simulation, from time <code>0</code> to the current model time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For long running simulations, with lots variables, using an infinite range can |
| lead to large numbers of data points, which can have a significant effect on |
| performance. This applies especially for live plotting mode.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-data">Data points</h7> |
| <div class="paragraph"> |
| <p>This section describes which data points are visualized. For most users, this |
| will be of little interest, as it essentially works as you would expect.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The plot visualizer adds data points (a <code>time</code> value and a value of a |
| variable at that time) for all variables, for the following |
| <a href="#tools-cifsim-traces-state">states</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The initial state of the simulation.</p> |
| </li> |
| <li> |
| <p>The start state of every time transition.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-realtime-frames">Intermediate states</a> of time |
| transitions, only if real-time simulation is enabled.</p> |
| </li> |
| <li> |
| <p>Trajectory data points of time transitions, only if real-time simulation is |
| disabled.</p> |
| </li> |
| <li> |
| <p>The end state of every time transition.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For real-time simulation, the amount of model time between two intermediate |
| states is the <a href="#tools-cifsim-output-realtime-delta">model time delta</a>, |
| and can be influenced using the |
| <a href="#tools-cifsim-output-realtime-framerate">frame rate</a> and |
| <a href="#tools-cifsim-output-realtime-simspeed">simulation speed</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For non real-time simulation, the trajectory data points are determined by the |
| <a href="#tools-cifsim-solver-chapter-basics-int">ODE solver integrator</a>, and can be |
| influenced using the <a href="#tools-cifsim-solver-chapter-options">integration options</a>, |
| as well as the <a href="#tools-cifsim-solver-chapter-options-outstep">fixed output step size</a> option.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-trajdata-relation">Relation to trajectory data output</h7> |
| <div class="paragraph"> |
| <p>The plot visualizer can be used for simple plotting. It can be customized a bit |
| through options, as described above. However, the level of customization is |
| somewhat limited. For instance, the appearance can not be customized. This is |
| intentional.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If further customization is required, use the |
| <a href="#tools-cifsim-output-chapter-trajdata">trajectory data output component</a> |
| instead. It allows saving the data to a file, for further processing with |
| external tools, such as |
| <a href="http://www.r-project.org/">R</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Such post processing is then performed after the simulation has |
| <a href="#tools-cifsim-chapter-termination">ended</a>. A benefit of the plot visualizer, is |
| that it allows live plotting mode, without the need of post processing, and |
| which can be enabled with little effort. The plot visualizer is meant to be |
| used only to get a basic understanding of how values of variables change as |
| time progresses.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-plotviz-trajdata-save">Saving a plot image</h7> |
| <div class="paragraph"> |
| <p>The plot visualizer can export the currently visible plot to several different |
| image formats. To export the image, first make sure that the plot visualizer |
| has the focus. Then select <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Save As…​</b></span> to open the |
| <b class="menuref">Save plot as</b> |
| dialog. Alternatively, right click the plot itself, |
| and choose |
| <b class="menuref">Save As…​</b> |
| from the popup menu, to open the |
| <b class="menuref">Save plot as</b> |
| dialog. In the dialog, specify the file name of the |
| exported image. Click |
| <b class="button">OK</b> |
| to confirm and continue.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A second dialog appears, in which the size of the exported image can be |
| specified. By default, the current size of the visualizer is used. A custom |
| size can be entered. The width and height need to specified in pixels, |
| separated by a <code>x</code> character. For instance, for a width of <code>640</code> pixels and |
| a height of <code>480</code> pixels, enter <code>640x480</code> into the dialog. Click <code>OK</code> to |
| confirm and to actually export the image.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following |
| <a href="http://en.wikipedia.org/wiki/Raster_graphics">raster image</a> |
| formats are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Portable_Network_Graphics">Portable Network Graphics</a> |
| (<code>*.png</code>)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/JPEG">JPEG</a> |
| (<code>*.jpg</code>)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Graphics_Interchange_Format">Graphics Interchange Format</a> |
| (<code>*.gif</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The image format that is used to export the image, is derived from the file |
| extension that is used. For each of the supported file formats, the allowed |
| file names (with file extensions) are indicated above (between parentheses).</p> |
| </div> |
| <div class="paragraph"> |
| <p>After the image is exported, the workspace is refreshed to show that new image |
| file, if the image was saved in a project that is visible in the |
| 'Project Explorer' tab or 'Package Explorer' tab.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In order for the export to succeed, data points must be available for at least |
| two time values.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-undoreset-5">Undo/reset</h7> |
| <div class="paragraph"> |
| <p>It is possible to go back in time, by |
| <a href="#tools-cifsim-input-history-reset-undo">undoing</a> one or more transitions, or |
| by <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If one or more transitions are undone, data for all time points that are then |
| suddenly in the future, are removed. More precisely, all data for time points |
| added for time transitions that have been undone, are removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the simulation is reset, the entire plot is cleared.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-stateviz">State visualizer</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The <a href="#tools-cifsim-output-chapter-normal">normal console output</a>, which may |
| include the <a href="#tools-cifsim-traces-state">state</a> of the specification, |
| is printed to the console. The entire state is then printed as a single line |
| of text, which can be hard to read as the specification grows, and the state |
| contains more and more variables. The <em>state visualizer</em> can be used as an |
| alternative. It shows the same information, but in a table in a separate |
| window. Here is an example screenshot of the visualizer:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/output/stateviz_sshot.png" alt="stateviz sshot"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div id="tools-cifsim-output-stateviz-option" class="paragraph"> |
| <p>Unlike <a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualization</a>, which |
| requires that the user makes an image of the system and couples the image to |
| the specification, the state visualizer can be used directly, without any |
| additional effort. All that is required to use it, is to enable it. The state |
| visualizer is disabled by default, and can be enabled using the |
| <b class="menuref">State visualization</b> |
| option (<b class="menuref">Output: State visualization</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-contents">Contents</h7> |
| <div class="paragraph"> |
| <p>The state visualizer shows all the discrete, continuous, and algebraic |
| variables of the specification, as well as their values. It also shows the |
| derivatives of the continuous variables, and their values. This includes |
| variable <code>time</code>, but not its derivative. It also shows the automata, with |
| their current locations. The variables and automata are listed in alphabetical |
| order, except for variable <code>time</code>, which is always shown at the top.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-icons-and-legend">Icons and legend</h7> |
| <div class="paragraph"> |
| <p>The icons on the left indicate the kind of object that is shown in a particular |
| row of the table:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cifsim/output/stateviz_aut.png" alt="stateviz aut"></span> |
| An automaton, with its current location.</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cifsim/output/stateviz_discvar.png" alt="stateviz discvar"></span> |
| A discrete variable, with its current value.</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cifsim/output/stateviz_contvar.png" alt="stateviz contvar"></span> |
| A continuous variable (includes variable <code>time</code>), |
| with its current value.</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cifsim/output/stateviz_deriv.png" alt="stateviz deriv"></span> |
| A derivative of a continuous variable (excludes variable |
| <code>time</code>), with its current value.</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cifsim/output/stateviz_algvar.png" alt="stateviz algvar"></span> |
| An algebraic variable, with its current value.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The values are updated for the initial state, states reached after transitions |
| (event transitions and time transitions), as well as for |
| <a href="#tools-cifsim-output-realtime-frames">frames</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-stateviz-filtering">Filtering</h7> |
| <div class="paragraph"> |
| <p>By default, all state objects are displayed by the state visualizer. Using |
| the |
| <b class="menuref">State visualization filters</b> |
| option |
| (<b class="menuref">Output: State visualization</b> |
| category), the state objects can |
| be filtered. The |
| <b class="menuref">State visualization filters</b> |
| option only has effect |
| if state visualization is enabled, using the |
| <b class="menuref">State visualization</b> |
| option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As value for the option, comma separated <em>filters</em> should be supplied. Each |
| filter specifies one or more state objects. The absolute names of the objects |
| are used. That is, for an automaton <code>a</code>, with a variable <code>x</code>, the absolute |
| name of the variable object is <code>a.x</code>. If CIF textual syntax keyword are |
| used as names for events (such as <code>plant</code>), then they must be escaped in |
| <code>.cif</code> files (<code>$plant</code>). For filters however, all escape characters (<code>$</code>) |
| in the names are ignored. The <code>*</code> character can be used as wildcard, to |
| indicate zero or more characters. If a filter doesn’t match any of the state |
| objects of the CIF model, a warning is printed to the console. A warning is |
| also printed if the entire state is filtered out.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, filters include matching state objects. Filters may however be |
| preceded by a <code>-</code> character, turning them into exclusion filters, which |
| exclude matching states objects rather than including them. Filters are |
| processed in the order they are specified, allowing for alternating additions |
| and removals. If a filter does not result in the addition/removal of any state |
| objects to/from the filter result, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, option value <code>a.*,-a.b*,a.bc*</code> consists of three filters: |
| <code>a.*</code>, <code>-a.b*</code>, and <code>a.bc*</code>. The first filter indicates that state |
| objects whose absolute names start with <code>a.</code> are to be included. The second |
| filter indicates that from those matching state objects, the state objects |
| whose absolute names start with <code>a.b*</code> are to be excluded. To that result, |
| the third filter adds those state objects whose absolute names start with |
| <code>a.bc*</code>. For instance, if a specification contains state objects <code>time</code>, |
| <code>a.a</code>, <code>a.b</code> <code>a.bb</code>, <code>a.bc</code>, <code>a.b.c</code>, <code>a.bc</code>, <code>a.bcc</code>, and |
| <code>a.bcd</code>, the result of the three filters is that the following state objects |
| are displayed: <code>a.a</code>, <code>a.bc</code>, <code>a.bc</code>, <code>a.bcc</code>, and <code>a.bcd</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default option value (filter) is <code>*</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-multiple-state-visualizers">Multiple state visualizers</h7> |
| <div class="paragraph"> |
| <p>By default, only one visualizer is shown. However, using the |
| <b class="menuref">State visualization filters</b> |
| option |
| (<b class="menuref">Output: State visualization</b> |
| category), it is possible to specify |
| that multiple visualizers should be used. The option allows for filtering of |
| the state objects, as described above. However, such filters can be separated |
| by semicolons, to specify the filters per visualizer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As an example, consider option value <code>time,a.x;b.y</code>. This results in two |
| state visualizers. The first one displays state objects <code>time</code> and <code>a.x</code>, |
| while the second one displays state object <code>b.y</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-undoreset-6">Undo/reset</h7> |
| <div class="paragraph"> |
| <p>By <a href="#tools-cifsim-input-history-reset-undo">undoing</a> one or more transitions, |
| or by <a href="#tools-cifsim-input-history-reset-undo">resetting</a> the simulation, the |
| state may change. The state visualizer is automatically updated to reflect such |
| changes.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-output-chapter-realtime">Real-time simulation</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF simulator allows for a form of real-time simulation. By enabling |
| real-time simulation, the simulator interprets the model time (the value of |
| variable <code>time</code>) in seconds. The simulator attempts to ensure that the actual |
| simulation time is equal to the model time. This feature is very useful for |
| visualizers, which then visualize their output at a steady rate. Without |
| real-time simulation, the rate at which such visualizers would visualize their |
| output, would primarily be determined by the amount of time it takes for the |
| simulator to compute the output, leading to abrupt slow downs and sudden speed |
| increases.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-realtime-frames">Frames</h7> |
| <div class="paragraph"> |
| <p>If real-time simulation is disabled, visualizations are only updated for the |
| <a href="#tools-cifsim-traces-state">states</a> that are reached. That is, the |
| visualizations are updated for the initial state, and each new state that is |
| reached after taking a transition. The visual representations of the |
| visualizations resulting from these states are called <em>frames</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As time progresses, the values of continuous variables (and algebraic variables |
| for which the value is directly or indirectly derived from a continuous |
| variable, etc) change. If the visualization is only updated before and after |
| time transitions, as is done when real-time simulation is disabled, this leads |
| to 'jumps' in the visualization. For real-time simulation, the simulator |
| calculates states that are evenly spaced over time. This ensures that we get |
| regular updates of the visualizations, as time progresses, and the |
| visualizations thus become 'smooth' or 'fluent'. If enough states are |
| visualized per second, a visualization essentially becomes a <em>movie</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| The states that result from transitions are always calculated. For real-time |
| simulation, the simulator calculates additional states for the purpose |
| of visualization, as mentioned above. These additional states are called |
| <em>intermediate states</em>, and the corresponding visual representations of the |
| visualizations to which they lead are called <em>intermediate frames</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For real-time simulation, the simulator thus uses intermediate frames that are |
| evenly spaced over time, for smooth visualizations. A consequence of this, is |
| that state changes between those intermediate frames are lost. If the effect is |
| still visible in the next intermediate state, this is not a problem. If however |
| the effect is temporary, and does not last until the next intermediate state, |
| the effect is thus not visualized.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For real-time simulation combined with an interactive |
| <a href="#tools-cifsim-input-chapter-index">input mode</a>, the |
| simulator uses both the state frames and the intermediate frames. This ensures |
| that at the moment an interactive choice has to be made about which |
| transition to take, the visualization reflects the current state of the system. |
| Semi-automatic mode is not taken into account.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-realtime-framerate">Frame rate</h7> |
| <div class="paragraph"> |
| <p>Using the |
| <b class="menuref">Frame rate</b> |
| option (<b class="menuref">Output</b> |
| category), it is |
| possible to specify how often per second of real time, visualizations should |
| be updated. A higher frame rate leads to more updates per second, and thus to |
| a more fluent visualization. However, since a higher frame rate also leads to |
| more frequent updates, the amount of CPU power it takes to perform these |
| updates increases as well. If the computer can not update the visualization in |
| time for the next update to take place, the visualization may start to |
| 'stutter'.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The frame rate will thus always be a compromise between fluency and |
| performance. Choosing an appropriate frame rate depends not only on the |
| complexity of the specification being simulated and the visualization that is |
| being shown, but also on the computer on which the simulation is run. |
| Furthermore, it may depend on the other tasks the computer is performing while |
| the simulation is being run.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Frame rates are always positive, and may be fractional. For instance, a frame |
| rate of <code>7.5</code> is valid, and will update the visualization 7.5 times per |
| second.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A low frame rate (typically less than 10 frames per second) can have a |
| devastating effect on the |
| <a href="#tools-cifsim-input-svg-simulation-responsiveness">responsiveness of SVG input</a>. |
| Similarly, it can hinder |
| <a href="#tools-cifsim-chapter-termination">termination</a> of the simulation, as the red |
| <em>Terminate</em> button has no effect between intermediate frames. That is, the |
| effect of clicking the button is postponed until the next frame, or until the |
| time transition ends.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-realtime-simspeed">Simulation speed</h7> |
| <div class="paragraph"> |
| <p>If real-time simulation is enabled, the simulator by default interprets the |
| model time (the value of variable <code>time</code>) in seconds. However, this can be |
| changed using the |
| <b class="menuref">Simulation speed</b> |
| option (<b class="menuref">Output</b> |
| category). This option specifies a scaling factor. A scaling factor of <code>1.0</code> |
| interprets model time as seconds, <code>2.0</code> is twice as fast (1 unit of model |
| time takes 0.5 seconds), etc. The simulation speed must always be positive, |
| and may be fractional. For instance, a simulation speed of <code>0.5</code> is valid, |
| and will interpret model time as twice as slow (1 unit of model time takes 2 |
| seconds).</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-enabling-real-time-simulation">Enabling real-time simulation</h7> |
| <div class="paragraph"> |
| <p>By default, real-time simulation is disabled, and the simulator will try to |
| simulate as fast as possible (infinite speed, taking time transitions takes no |
| time). By setting a frame rate and/or a simulation speed, real-time simulation |
| can be enabled. If only one of the options is specified, the other gets a |
| default value. The default frame rate for real-time simulation is <code>20.0</code> |
| frames per second. The default simulation speed is <code>1.0</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div id="tools-cifsim-output-realtime-outcomp" class="paragraph"> |
| <p>Enabling real-time simulation requires a real-time output component |
| (visualizer). Currently, the following real-time output components are |
| available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualizer</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If real-time simulation is enabled without using a real-time output component, |
| simulation can’t be started. Closing the visualizer of a real-time simulation |
| during the simulation, if it is the last remaining real-time output component, |
| leads to the simulation being <a href="#tools-cifsim-chapter-termination">stopped</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All real-time output components can also be used when real-time simulation is |
| disabled, but obviously without any real-time effects.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-output-realtime-delta">Model time delta</h7> |
| <div class="paragraph"> |
| <p>The simulation speed does not influence the frame rate. That is, both options |
| can be specified orthogonally. The two options together however, do influence |
| the model time delta, the amount of model time between two consecutive updates |
| of the visualizations, i.e. the amount of model time between two consecutive |
| intermediate frames. The model time delta is calculated using the following |
| formula (where <code>r</code> is the frame rate, and <code>s</code> is the simulation speed): |
| 1 / (<code>r</code> / <code>s</code>). Doubling the frame rate results in half the model time |
| delta, while doubling the simulation speed results in double the model time |
| delta.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the model time delta becomes to big, this may lead to 'jumps' in the |
| visualization. In such cases, increasing the frame rate, or reducing the |
| simulation speed causes a smaller model time delta, leading to a more fluent |
| visualization.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The model time delta (and thus the frame rate and simulation speed) also |
| affects the <a href="#tools-cifsim-solver-chapter-options-outstep">ODE solver fixed output step size</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-test-mode">Test mode</h7> |
| <div class="paragraph"> |
| <p><a href="#tools-cifsim-chapter-test-mode">Test mode</a> disables all real-time delays of |
| the real-time simulation mode, but still updates the visualizations for the |
| intermediate frames. With test mode enabled, it is also allowed to perform a |
| real-time simulation without real-time output component.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-simulation-advanced-topics">Simulation advanced topics</h4> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-options">Simulator options</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator can be configured via various options. The available |
| options are listed below, per category.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>General</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Help</em>: Prints the help text of the application to the console.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-mode">Output mode</a></p> |
| </li> |
| <li> |
| <p><em>License</em>: Prints the license text of the application to the console.</p> |
| </li> |
| <li> |
| <p><em>Developer mode</em>: Option to control whether exceptional situations return |
| limited and user-friendly information (the default), or extended developer |
| oriented information. This option is primarily intended for the developers of |
| the CIF simulator, and should not be used by end users.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Simulation</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>CIF specification</em>: The absolute or relative local file system path to the |
| CIF specification (<code>.cif</code> file) to simulate. May also be a |
| <a href="#tools-cifsim-chapter-repeated-simulation">compiled code file</a> (<code>.cifcode</code> |
| file).</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-init">CIF specification initialization</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-termination-endtime">Simulation end time</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-endtime-maxdelay">Maximum delay</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-distr-seeds">Initial seed for stochastic distributions</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-complete-mode">Complete mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-extfuncs-async">External functions asynchronous execution</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-profiling">Profiling</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-termination-confirm">Ask to confirm simulator termination</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-max-time-point-tol">Maximum time point tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-debug-gen-code">Load debug code</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Compiler</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-repeated-sim-compile-once">Compile only</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-repeated-sim-compile-once">Compiled code file</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-java-compiler">Java compiler</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Input</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-index">Input mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-automatic-trans">Automatic mode choice algorithm</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-automatic-time">Automatic mode time transition duration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-trace-file">Trace input file</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-chapter-semi-automatic">Interactive mode automatic transition choice</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-env-events">Environment events</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-history-enable">History</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-input-history-size">History size</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Output</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-normal">Normal output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-normal-state-filter">Normal output state filters</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-debug">Debug output</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-realtime-framerate">Frame rate</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-realtime-simspeed">Simulation speed</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-test-mode">Test mode</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Output: SVG visualization</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-simulation-option">SVG visualization</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Output: Trajectory data</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-trajdata-option">Trajectory data</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-trajdata-file">Trajectory data file</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-trajdata-filters">Trajectory data filters</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-trajdata-sep">Trajectory data separation amount</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Output: Plot visualization</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-plotviz-option">Plot visualization</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-plotviz-mode">Plot visualization mode</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-plotviz-filtering">Plot visualization filters</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-plotviz-range">Plot visualization range</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Output: State visualization</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-stateviz-option">State visualization</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-stateviz-filtering">State visualization filters</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>ODE solver</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-options-outstep">ODE solver fixed output step size</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>ODE solver: ODE integrator</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-algo">ODE solver integrator algorithm</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-tol">ODE solver integrator absolute tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-tol">ODE solver integrator relative tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-step">ODE solver integrator minimum step size</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-step">ODE solver integrator maximum step size</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-int-numstep">ODE solver integrator number of steps</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>ODE solver: ODE root finder</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-root-maxcheck">ODE solver root finder maximum check interval</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-root-algo">ODE solver root finding algorithm</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-root-tol">ODE solver root finder absolute tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-root-tol">ODE solver root finder relative tolerance</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-options-root-maxiter">ODE solver root finder maximum iterations</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-performance">Simulation performance</h5> |
| <div class="paragraph"> |
| <p> |
| |
| General performance information about Java or Eclipse typically applies to the |
| CIF simulator as well. This page provides additional information specific to |
| the CIF simulator.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-closing-the-simulator">Closing the simulator</h6> |
| <div class="paragraph"> |
| <p>Closing the simulator ensures that all its resources are freed, and become |
| available for other applications. |
| The CIF simulator however, may ask you to press <kbd>ENTER</kbd> to |
| <a href="#tools-cifsim-termination-confirm">confirm termination</a> of the |
| simulator. If asked, as long as you haven’t pressed <kbd>ENTER</kbd> yet, the |
| status of the console will still show it’s running, and the application can’t |
| release its resources.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-slow-starting-of-the-simulator">Slow starting of the simulator</h6> |
| <div class="paragraph"> |
| <p>If simulation is slow to start, you can try a different |
| <a href="#tools-cifsim-chapter-java-compiler">Java compiler</a>. You can also try to |
| <a href="#tools-cifsim-repeated-sim-compile-once">compile the model once</a>, |
| reducing the start time of the simulator for |
| <a href="#tools-cifsim-chapter-repeated-simulation">repeated simulations</a>.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-slow-termination-of-the-simulator">Slow termination of the simulator</h6> |
| <div class="paragraph"> |
| <p>If termination of the simulator is slow, this may be related to |
| the <a href="#tools-cifsim-output-chapter-trajdata">trajectory data output component</a>. |
| If its <a href="#tools-cifsim-output-trajdata-prettify">prettifying</a> option is |
| enabled, it will read the trajectory data file after the simulation terminates, |
| and write the whole file again in a prettier from. This may take some time, |
| especially on slow remote/network file systems or storage devices. Disabling |
| the option or the trajectory data output may solve this problem, as may |
| switching to a faster file system or storage device.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-value-simplification">Value simplification</h6> |
| <div class="paragraph"> |
| <p>By applying the <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> CIF to CIF transformation |
| before simulation, you may be able to simplify the specification, and thus |
| improve the performance of both starting up the simulator, as well as the |
| actual simulation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-simulation-options">Simulation options</h6> |
| <div class="paragraph"> |
| <p>Various simulation options can be tweaked to increase the simulation |
| performance:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-console">Console output</a></p> |
| <div class="paragraph"> |
| <p>Reducing the amount of console output significantly improves simulation |
| performance.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-components">Output components</a></p> |
| <div class="paragraph"> |
| <p>By disabling certain output components, the simulator needs to do less work, |
| and this may improve the performance of the simulation.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-chapter-realtime">Real-time simulation</a></p> |
| <div class="paragraph"> |
| <p>The performance and perceived 'smoothness' or 'fluency' of visualizations can |
| be influenced via the |
| <a href="#tools-cifsim-output-realtime-framerate">frame rate</a> and |
| <a href="#tools-cifsim-output-realtime-simspeed">simulation speed</a>.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-endtime-maxdelay">Maximum delay</a></p> |
| <div class="paragraph"> |
| <p>By decreasing the maximum allowed length of a single time transition, shorter |
| time transitions are calculated, which takes less time. After the shorter |
| time delay, the simulator will calculate the remainder of the time |
| transition. Essentially, the time transitions are cut into parts, which are |
| calculated separately, over time. As such, the calculation time is spread |
| out over time as well. This can make |
| <a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualizations</a> feel more fluent. However, each time |
| transition calculation has a certain amount of overhead, so reducing the |
| maximum delay too much is not a good idea.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-chapter-complete-mode">Complete mode</a></p> |
| <div class="paragraph"> |
| <p>By disabling the complete mode, the simulator has to perform less work to |
| calculate the possible transitions, improving the simulation performance.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-index">Solver</a></p> |
| <div class="paragraph"> |
| <p>The ODE solver options can be used to make the ODE solver faster, usually at |
| the expense of accuracy. For instance, increasing the various tolerances |
| reduces the number of calculations needed by the ODE solver, but makes the |
| calculated trajectories less accurate. Switching algorithms may also improve |
| the performance, as may increasing the maximum check interval.</p> |
| </div> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-extfuncs-async">External functions synchronous execution</a></p> |
| <div class="paragraph"> |
| <p>Using synchronous execution for external user-defined functions reduces |
| their execution overhead.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-solver-chapter-index">ODE solver</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| During time transitions, the values of the continuous variables and their |
| derivatives change. These changes are calculated using an |
| <a href="http://en.wikipedia.org/wiki/Ordinary_differential_equation">ODE</a> |
| <a href="http://en.wikipedia.org/wiki/Numerical_ordinary_differential_equations">integrator</a>. |
| As soon as a guard for an event becomes enabled, time should no longer |
| progress. To calculate whether (and when) guards change value, a |
| <a href="http://en.wikipedia.org/wiki/Root-finding_algorithm">root finding algorithm</a> |
| is used. |
| Software to solve ODEs, through integration and root finding, are often called |
| ODE solvers. The CIF simulator uses the |
| <a href="http://commons.apache.org/proper/commons-math/">The Apache Commons Mathematics Library</a>. |
| This library |
| contains ODE solvers, with several different integrators and root finding |
| algorithms.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Debug information about what the ODE solver calculates, and for what time |
| points, can be enabled using the <em>Debug output</em> option. See the |
| <a href="#tools-cifsim-output-chapter-debug">Debug console output</a> page for more information.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Basic topics</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-basics-int">The basics of numeric integration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-basics-root">The basics of numeric root finding</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-root-problems">Problems with root finding</a> (and missed guards/events)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-options-outstep">Fixed output step size</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p><strong>Advanced topics</strong></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-endtime-maxdelay">Simulation end time and maximum delay</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-options">ODE solver integrator options</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-solver-chapter-options-root">ODE solver root finder options</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-basics-int">The basics of numeric integration</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| During time transitions, the values of the continuous variables and their |
| derivatives change. The derivatives have explicit equations, the continuous |
| variables change according to the value of their derivatives. Using the |
| equations for the derivatives as a system of |
| <a href="http://en.wikipedia.org/wiki/Ordinary_differential_equation">ordinary differential equations</a> |
| (ODEs), |
| together with the initial values of the continuous variables as the <em>initial |
| conditions</em>, this essentially comes down to solving an |
| <a href="http://en.wikipedia.org/wiki/Initial_value_problem">initial value problem</a> |
| (IVP).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Such problems can be solved through |
| <a href="http://en.wikipedia.org/wiki/Integral">integration</a>. |
| For some problems it is possible to do this |
| <a href="http://en.wikipedia.org/wiki/Symbolic_integration">symbolically</a>. |
| For more complex systems of ODEs however, |
| <a href="http://en.wikipedia.org/wiki/Numerical_ordinary_differential_equations">numerical methods</a> |
| are used. The CIF simulator uses |
| <a href="http://commons.apache.org/proper/commons-math/">The Apache Commons Mathematics Library</a>, |
| which contains several numerical integrators.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-linear-ode">Linear ODE</h7> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification, with a linear ODE:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont x = 0.0; |
| equation x' = 1.0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The solution to this IVP, is the values of continuous variable <code>x</code> and its |
| derivative <code>x'</code>, as function of variable <code>time</code>:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/integr_linear.png" alt="integr linear"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the numerical integrator start with the initial value of continuous |
| variable <code>x</code>, which is <code>0.0</code>. For the initial value of variable <code>time</code>, |
| which is also <code>0.0</code>, it computes <code>x'</code>, which is <code>1.0</code>. It then slightly |
| increases the value of variable <code>time</code> to say <code>1e-6</code>. Assuming a linear |
| continuous variable <code>x</code>, the value of variable <code>x</code> at that time is <code>1e-6</code> |
| as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The numerical integrator tries to predict the values of the derivative as time |
| progresses. It gradually increases the value of variable <code>time</code>, predicting |
| the value of the derivative at the next time point. If the next prediction |
| closely matches the actual calculated value, the integrator moves on to the |
| next time point. If the next prediction is not close enough to the actual |
| calculated value of the derivative for that time point, more intermediate |
| values are calculated. That is, the integrator tries to approximate the |
| derivative as time progresses, while increasing the time between two |
| consecutive time points. As long as the predictions match the actual |
| calculated value of the derivative at the next time point, it keeps increasing |
| the step size even further. If the predictions are not good enough (the |
| difference with the actual calculated value is above a certain tolerance), more |
| intermediate time points are investigated. The values calculated for those |
| time points can then be used to come up with a better approximation, that |
| better predicts the value of the derivative at future time points.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the linear ODE given above, the <a href="#tools-cifsim-output-chapter-trajdata">trajectory data</a> |
| calculated by the integrator is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code># time x x' |
| 0.0 0.0 1.0 |
| 9.999999999999999e-5 1.0000000000000003e-4 1.0 |
| 0.0011 0.0011000000000000005 1.0 |
| 0.0111 0.011100000000000006 1.0 |
| 0.1 0.10000000000000006 1.0</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Note that the time points for which the values were calculated, are indicated |
| in the figure above by small plus signs (<code>+</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-nonlinear-ode">Nonlinear ODE</h7> |
| <div class="paragraph"> |
| <p>The approximations of the integrator don’t need to be linear. Some integrators |
| for instance support |
| <a href="http://en.wikipedia.org/wiki/Nonlinear#Nonlinear_differential_equations">nonlinear differential equations</a>. |
| Consider the following CIF specification, with such a nonlinear ODE:</p> |
| </div> |
| <div class="paragraph"> |
| <p>The solution calculated by the numerical integrator is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont x = 0.0; |
| equation x' = (x * x) - x - 2;</code></pre> |
| </div> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/integr_nonlinear.png" alt="integr nonlinear"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, we see how the step size is increased initially, as the linear |
| approximation is good enough. As soon as we get to the bend, the step size is |
| reduced to better approximate the actual values. After the bend, the step size |
| is slowly increased again. The integrator internally uses a polynomial of a |
| higher degree to approximate this differential equation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-discontinuities">Discontinuities</h7> |
| <div class="paragraph"> |
| <p>If the derivative has a |
| <a href="http://en.wikipedia.org/wiki/Discontinuity_%28mathematics%29">discontinuity</a>, |
| such as in the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">cont x = 1.0; |
| equation x' = if x < 2: 1.0 |
| else 3.0 |
| end;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The integrator will try to figure out the time point at which the discontinuity |
| occurs, by decreasing the step size as it nears the discontinuity. After the |
| discontinuity, the step size is gradually increased, as integration continues:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/integr_discont.png" alt="integr discont"> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-basics-root">The basics of numeric root finding</h6> |
| <div class="paragraph"> |
| <p> |
| |
| During time transitions, the values of the continuous variables and their |
| derivatives change. If continuous variables or their derivatives are (directly |
| or indirectly) used in guards of edges, changes in their values may result in |
| the guard becoming enabled, as time progresses. To detect such changes during |
| <a href="#tools-cifsim-solver-chapter-basics-int">integration</a>, a |
| <a href="http://en.wikipedia.org/wiki/Root-finding_algorithm">root finding algorithm</a> |
| can be used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| cont x = 0.0; |
| equation x' = 0.5; |
| |
| location: |
| initial; |
| edge when x >= 1.5 do x := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the value of continuous variable <code>x</code> increases with <code>0.5</code> every time |
| unit. Once the value of <code>1.5</code> is reached, the variable is reset to <code>0.0</code>. |
| This process is repeated:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_simple.png" alt="root simple"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If we look at the data calculated by the numerical integrator, to solve the ODE |
| problem:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_simple2.png" alt="root simple2"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>we see that values are calculated for time points <code>1.1111</code> and <code>5.0</code>. If we |
| then also look at the value of the guard, where we use value <code>-1</code> for |
| <code>false</code> and <code>+1</code> for <code>true</code>:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_simple_guard.png" alt="root simple guard"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>we see that at time <code>1.1111</code>, the value of the guard is <code>-1</code> (<code>false</code>). |
| At time <code>5.0</code> it is <code>+1</code> (<code>true</code>). That is, the guard changed value |
| between two time points calculated by the integrator. If this is the case, the |
| ODE solver tries to calculate the exact time point at which the guard changes |
| its value. That is, it calculates the exact time point at which the guard |
| function crosses the time axis, and thus has a |
| <a href="http://en.wikipedia.org/wiki/Zero_of_a_function">root</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| One of the simplest root finding algorithms, is the |
| <a href="http://en.wikipedia.org/wiki/Bisection_method">bisection method</a>. |
| This algorithm starts with |
| the two time points where the guard has opposite |
| <a href="http://en.wikipedia.org/wiki/Sign_%28mathematics%29">signs</a>. |
| This is the interval |
| where the guard sign change occurs (it contains the root). The bisection method |
| tries to reduce the size of the interval, by calculating the value of the guard |
| in the middle of the interval. Depending on the sign of the value of the guard |
| at this middle point, this middle point replaces either the lower bound or the |
| upper bound of the interval. This is done in such a way that the values of the |
| guard at the lower and upper bound of the interval have opposite signs, and the |
| interval thus <em>brackets</em> the root.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the example above, the root is calculated as follows:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_root.png" alt="root root"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We start with the interval <code>[1.1111 .. 5.0]</code>. The middle point is <code>3.0555</code> at which |
| the guard holds, just like the upper bound (at <code>5.0</code>). Thus <code>5.0</code> is replaced by |
| <code>3.0555</code>. The middle point of <code>1.1111</code> and <code>3.0555</code> is <code>1.5972</code>. Since the guard holds |
| for time <code>1.5972</code>, upper bound <code>3.0555</code> is replaced by <code>1.5972</code>. The middle point |
| of <code>1.1111</code> and <code>1.5972</code> is <code>1.3542</code>. The guard does not hold at time <code>1.3542</code>, so the |
| lower bound of <code>1.1111</code> (at which the guard does not hold) is replaced by <code>1.3542</code>. |
| This process continues until the interval is smaller than a certain tolerance |
| value. Once we have that interval, we can choose a value from the interval as |
| the computed root.</p> |
| </div> |
| <div class="paragraph"> |
| <p>While the bisection method is relatively simple, the root finding algorithms |
| used by the CIF simulator work using the same principles. However, they |
| converge much faster. That is, they requires much less iterations of updating |
| the bounds, to get to a satisfactory answer.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-root-problems">Problems with root finding</h6> |
| <div class="paragraph"> |
| <p> |
| With <a href="#tools-cifsim-solver-chapter-basics-root">numeric root finding</a>, there is |
| the risk of missing guard changes, which means there is the risk of missing |
| event transitions.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-the-problem">The problem</h7> |
| <div class="paragraph"> |
| <p>To illustrate the problem, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| cont x = 0.0; |
| equation x' = 1.0; |
| |
| location: |
| initial; |
| edge when x >= 2.33 and x <= 2.34 do x := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification, when simulated using the CIF simulator, using default |
| settings, results in:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_problem.png" alt="root problem"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>From the image, where the values calculated by the integrator are indicated |
| using small plus signs (<code>+</code>), we can see that for times <code>2.1111</code> and |
| <code>2.6111</code>, the integrator calculated points. Since the function is linear |
| between those two time points, no additional intermediate time points were |
| investigated. Since the guard becomes <code>true</code> after time point <code>2.1111</code> (at |
| time point <code>2.33</code>) and also becomes <code>false</code> again before time point |
| <code>2.61111</code> (at time point <code>2.34</code>), the integrator misses the guard change. |
| That is, for every time point that the guard is evaluated, it is <code>false</code>, and |
| the change in guard value is thus not detected. We miss the guard, and thus |
| the event that resets variable <code>x</code> to <code>0.0</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-solution-1-maximum-check-interval">Solution 1: maximum check interval</h7> |
| <div class="paragraph"> |
| <p>The first solution is to use the |
| <b class="menuref">ODE solver root finder maximum check interval</b> |
| option (<b class="menuref">ODE solver: ODE root finder</b> |
| category). This |
| option can be used to set the maximum time interval between two consecutive |
| checks of the sign of the guard. By default, this is <code>0.5</code> time units. If we |
| set this value to <code>0.001</code>, then we ensure that at least once every <code>0.001</code> |
| time units, the guard sign is checked. This means that between time points |
| <code>2.1111</code> and <code>2.61111</code>, the guard will be checked approximately 500 times. |
| This also means that between time points <code>2.33</code> and <code>2.34</code>, the guard will |
| be checked approximately 10 times. Therefore, this ensures that we check a time |
| point just before time <code>2.33</code>, and one just after it, which means we can’t |
| miss the guard change.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the above example, <code>x'</code> is <code>1.0</code>. If however <code>x'</code> would be <code>2.0</code>, |
| then the time interval where the guard is enabled reduces from <code>0.01</code> time |
| units to <code>0.005</code> time units. Using a maximum check interval of <code>0.001</code> |
| would then still suffice, as the guard would be checked approximately 5 times |
| in that time interval. If however <code>x'</code> is <code>100</code>, then the time interval |
| would become <code>0.0001</code>, which is smaller than the maximum check interval of |
| <code>0.001</code>. That is, the derivatives of the values occurring in guards influence |
| the value that should be chosen for the maximum delay interval.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, to choose an appropriate value for the maximum check interval, not |
| only the the ranges of values of the variables where the guard is enabled |
| should be taken into account, but the steepness of their derivatives as well. |
| That is, the value of the maximum check interval should be based on the time |
| interval where the guard is enabled. Choosing half the duration of the smallest |
| of such time intervals, for all guards, is generally a good choice.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Note that choosing a smaller interval results in more guard change checks, and |
| thus negatively impacts the performance of the simulation. Therefore, choosing |
| a maximum check interval that is unnecessarily small also unnecessarily |
| reduces performance of the simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-solution-2-splitting-the-guard">Solution 2: splitting the guard</h7> |
| <div class="paragraph"> |
| <p>We can reformulate the original CIF specification, by splitting the guard:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| cont x = 0.0; |
| equation x' = 1.0; |
| |
| location: |
| initial; |
| edge when x >= 2.33, x <= 2.34 do x := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification, when simulated using the CIF simulator, using default |
| settings, results in:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/cifsim/solver/root_problem2.png" alt="root problem2"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The difference with the original specification is the guard of the edge. In the |
| original specification, the <code>and</code> binary operator is used, making it a single |
| guard. In the new specification, a comma (<code>,</code>) is used, which constructs two |
| separate guards. Both guards can be individually checked by the root finding |
| algorithm. As shown in the image, each of the guards changes value only once.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The comma between guards means that both guards have to hold, in order for the |
| edge to be enabled. This is similar, but not identical, to the <code>and</code> binary |
| operator. For the <code>and</code> binary operator, the left hand side must be evaluated |
| before the right hand side, and the right hand side may only be evaluated if |
| the left hand side evaluates to <code>true</code>. This is called |
| <a href="http://en.wikipedia.org/wiki/Short-circuit_evaluation">short-circuit evaluation</a>. |
| For guards separated by commas, no such relation may be assumed. That is, even if |
| the first guard evaluates to false, can the second guard still be evaluated by |
| the root finding algorithm, for guard changes. It can even be the case that the |
| second guard is evaluated before the first guard. These differences not only |
| influence root finding, but are also of particular interest when the right hand |
| side can result in a runtime evaluation failure. For instance, the following |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| cont x der 1.0; |
| location: |
| initial; |
| edge when x > 0, 1 / x < 0.5 do x := 0.0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>results in a runtime error. The second guard (<code>1 / x < 0.5</code>) is evaluated |
| even if the first guard (<code>x > 0</code>) does not hold. Initially, the first guard |
| does not hold, and the second guard results in division by zero. Changing the |
| comma between the guards to an <code>and</code> operator, makes it possible to simulate |
| this specification.</p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-debug-information">Debug information</h7> |
| <div class="paragraph"> |
| <p>Debug information about what the ODE solver calculates, and for what time |
| points, can be enabled using the <em>Debug output</em> option. This may be useful in |
| figuring out why the guard was missed, and what settings need to be changed. |
| See the <a href="#tools-cifsim-output-chapter-debug">Debug console output</a> page for more information.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-options-outstep">Fixed output step size</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The <a href="#tools-cifsim-solver-chapter-basics-int">integrator</a> determines the time |
| points for which values are calculated. By default, those points are included |
| in the trajectories. This means that they are also the output of the |
| <a href="#tools-cifsim-output-chapter-trajdata">trajectory data output component</a>. |
| The integrator determines the time points for which to calculate values, based |
| on the complexity of the ODEs. The integrator can be influenced using |
| the <a href="#tools-cifsim-solver-chapter-options">integrator options</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Sometimes however, it may be more convenient to have the integration output |
| at more regular intervals. Using the |
| <b class="menuref">ODE solver fixed output step size</b> |
| option (<b class="menuref">ODE solver</b> |
| category), a fixed output step size can be |
| configured. This value must be an integer or real number larger than zero.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This option does not influence the actual time points for which the integrator |
| calculates the values. Instead, it influences how these results are put in the |
| trajectories, that are subsequently used by the simulator.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Setting a fixed output step size, ensures that the trajectories contain output |
| for all multiples of the given step size. They will however also contain output |
| for the start and end of each time transition, which may not be at multiples |
| of the step size, due to guards becoming enabled or disabled at other times.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| If <a href="#tools-cifsim-output-chapter-realtime">real-time</a> simulation is enabled, the |
| default is changed to automatically use the |
| <a href="#tools-cifsim-output-realtime-delta">model time delta</a> that is used for |
| real-time simulation, as the fixed output step size. This way, the trajectories |
| contain the time points for which intermediate |
| <a href="#tools-cifsim-output-realtime-frames">frames</a> are generated. If |
| real-time simulation is enabled, setting a custom fixed output step size is |
| not supported.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-endtime-maxdelay">Simulation end time and maximum delay</h6> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The maximum length of a time transition is determined by several factors:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The current simulation time.</p> |
| </li> |
| <li> |
| <p>The simulation <a href="#tools-cifsim-termination-endtime">end time</a>.</p> |
| </li> |
| <li> |
| <p>The maximum allowed delay amount.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The current simulation time is the value of variable <code>time</code>. Each time |
| transition starts at the current time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using the |
| <b class="menuref">Simulation end time</b> |
| option (<b class="menuref">Simulator</b> |
| category), the <a href="#tools-cifsim-termination-endtime">end time</a> of the |
| simulation can be configured. By setting a simulation end time, you ensure that |
| when the value of variable <code>time</code> reaches that value, the simulation |
| <a href="#tools-cifsim-chapter-termination">terminates</a>. Settings a simulation end time |
| also limits the maximum length of a time transition, since from the current |
| time, a limited amount of time can pass before the end time is reached. By |
| default the simulation end time is set to 'infinite', which means that |
| simulation termination, and the maximum length of a time transition, are not |
| limited by a simulation end time.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Using the |
| <b class="menuref">Maximum delay</b> |
| option (<b class="menuref">Simulator</b> |
| category), |
| the maximum delay amount for a single time transition can be set. If set, no |
| time transitions longer than the specified value may be calculated. This limits |
| the maximum length of time transitions to that value. Essentially, this cuts |
| time transitions into parts with a maximum length specified by this option. By |
| default, the maximum delay is set to 'infinite', which means that the maximum |
| length of a time transition is not limited by this option. Restricting the |
| maximum delay amount for a time transition should generally be avoided. |
| For debugging purposes however, it may be useful to disable passage of time |
| altogether. This can be achieved by using a maximum delay of <code>0</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If both a simulation end time and a maximum allowed delay amount are specified, |
| the most restrictive of them determines the maximum length of the time |
| transition. If neither is specified, the simulator will attempt to calculate a |
| time transition of length <code>100.0</code>.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-options">ODE solver integrator options</h6> |
| <div class="paragraph"> |
| <p> |
| |
| The <a href="#tools-cifsim-solver-chapter-basics-int">integrator</a> used by the ODE solver |
| of the CIF simulator, can be configured using several options.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-int-algo">Integration algorithm</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver integrator algorithm</b> |
| option |
| (<b class="menuref">ODE solver: ODE integrator</b> |
| category) can be used to configure the |
| integrator algorithm to use. The following algorithms are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Higham and Hall 5(4)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Dormand-Prince">Dormand-Prince 5(4)</a></p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Dormand-Prince">Dormand-Prince 8(5,3)</a> |
| (default)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Bulirsch-Stoer_algorithm">Gragg-Bulirsch-Stoer</a></p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Adams_method">Adams-Bashforth</a> |
| (experimental)</p> |
| </li> |
| <li> |
| <p><a href="http://en.wikipedia.org/wiki/Adams_method">Adams-Moulton</a> |
| (experimental)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The algorithms differ in the complexity of the systems of ODEs that they can |
| handle, their performance, the precision of their results, etc. All these |
| algorithms use an |
| <a href="http://en.wikipedia.org/wiki/Adaptive_stepsize">adaptive step size</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-int-tol">Absolute and relative tolerance</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver integrator absolute tolerance</b> |
| option |
| (<b class="menuref">ODE solver: ODE integrator</b> |
| category) and the |
| <b class="menuref">ODE solver integrator relative tolerance</b> |
| option |
| (<b class="menuref">ODE solver: ODE integrator</b> |
| category), can be used to configure how |
| precise the results of the integrator should be. The lower the tolerance (or |
| error), the higher the precision of the results, but also the more computing |
| time it costs to get to that precision. The absolute precision is the |
| difference between the prediction and the actual value, while the relative |
| precision is that same difference, as a fraction of the actual value. In the |
| latter case, precision reduces with increasing values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-int-step">Minimum and maximum step size</h7> |
| <div class="paragraph"> |
| <p>The interval between two consecutive time points calculated by the integrator |
| can be configured using the |
| <b class="menuref">ODE solver integrator minimum step size</b> |
| option (<b class="menuref">ODE solver: ODE integrator</b> |
| category) and the |
| <b class="menuref">ODE solver integrator maximum step size</b> |
| option |
| (<b class="menuref">ODE solver: ODE integrator</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The default minimum step size is <code>1e-15</code> and the default maximum step size is |
| <code>0.5</code>. Note however that the last step can be smaller than the value |
| specified for the minimum step size option.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Increasing the maximum default step size may lead to better performance, but |
| can also lead to less precision, and <a href="#tools-cifsim-solver-chapter-root-problems">root finding problems</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-int-numstep">Number of steps</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver integrator number of steps</b> |
| option |
| (<b class="menuref">ODE solver: ODE integrator</b> |
| category) can be used to configure the |
| number of steps to use for the experimental |
| <a href="http://en.wikipedia.org/wiki/Adams_method">Adams-Bashforth</a> |
| and |
| <a href="http://en.wikipedia.org/wiki/Adams_method">Adams-Moulton</a> |
| integrators. The number of steps must be greater or equal to two.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-solver-chapter-options-root">ODE solver root finder options</h6> |
| <div class="paragraph"> |
| <p> |
| |
| The <a href="#tools-cifsim-solver-chapter-basics-root">root finder</a> used by the ODE |
| solver of the CIF simulator, can be configured using several options.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-root-maxcheck">Maximum check interval</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver root finder maximum check interval</b> |
| option |
| (<b class="menuref">ODE solver: ODE root finder</b> |
| category) is explained on a separate |
| page. See <a href="#tools-cifsim-solver-chapter-root-problems">Problems with root finding</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-root-algo">Root finding algorithm</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver root finding algorithm</b> |
| option |
| (<b class="menuref">ODE solver: ODE root finder</b> |
| category) can be used to configure the |
| root finding algorithm to use. The following algorithms are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Regula Falsi |
| (<a href="http://en.wikipedia.org/wiki/False_position_method">False position</a>) |
| method</p> |
| </li> |
| <li> |
| <p>Illinois method</p> |
| </li> |
| <li> |
| <p>Pegasus method (default)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The <em>Illinois</em> and <em>Pegasus</em> methods are modified <em>Regula Falsi</em> methods. The |
| algorithms differ only in how they choose the middle point of the interval. |
| This influences their convergence speed. The <em>Regula Falsi</em> method in |
| particular should be avoided in practice.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-root-tol">Absolute and relative tolerance</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver root finder absolute tolerance</b> |
| option |
| (<b class="menuref">ODE solver: ODE root finder</b> |
| category) and the |
| <b class="menuref">ODE solver root finder relative tolerance</b> |
| option |
| (<b class="menuref">ODE solver: ODE root finder</b> |
| category), can be used to |
| configure how precise the results of the root finder should be. The lower the |
| tolerance (or error), the higher the precision of the results, but also the |
| more computing time it costs to get to that precision. The absolute precision |
| is the difference between the prediction and the actual value, while the |
| relative precision is that same difference, as a fraction of the actual value. |
| In the latter case, precision reduces with increasing values.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cifsim-solver-options-root-maxiter">Maximum iterations</h7> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">ODE solver root finder maximum iterations</b> |
| option |
| (<b class="menuref">ODE solver: ODE root finder</b> |
| category) can be used to set the |
| maximum number of iterations to use for root finding. This value must be at |
| least one. If the root interval is larger than the tolerances allow, after the |
| maximum number of iterations, root finding fails.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If it fails for your CIF specification, increase the value of this option. If |
| that does not help, your specification is most likely too complex (by nature), |
| or has a modeling error that causes the specification to become too complex |
| for the root finding algorithm to handle. The problem however, may also be in |
| one of the other root finder options, or in one of the |
| <a href="#tools-cifsim-solver-chapter-options">integrator options</a>.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-java-compiler">Java compiler</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The simulator internally generates |
| <a href="http://oracle.com/java">Java</a> |
| code from |
| the CIF model. This code is compiled using a Java compiler and executed. Code |
| generation and compilation result in faster simulation. However, compilation |
| itself also takes time. The time it takes to compile is different for different |
| Java compilers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using the <em>Java Compiler</em> option (<em>Compiler</em> category), the Java compiler |
| implementation to use, can be configured. We currently provide two different |
| Java compilers:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Java compiler from the Java Development Kit (<code>jdk</code>)</p> |
| <div class="paragraph"> |
| <p>The Java Development Kit (JDK) that is required to use our tooling |
| includes a Java compiler. This compiler has the advantage that is has a bit |
| less overhead of accessing the file system, while it has as disadvantage that |
| it is a slower in actually compiling the Java code.</p> |
| </div> |
| </li> |
| <li> |
| <p>Eclipse Compiler for Java (<code>eclipse</code>)</p> |
| <div class="paragraph"> |
| <p>The Eclipse Compiler for Java (ecj) is part of the Eclipse Java Development |
| Tools (JDT), and is provided with our tooling. This compiler has the |
| advantage that is is a faster in actually compiling the Java code, while it |
| has as disadvantage that it has a bit more overhead of accessing the file |
| system.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The names given above, in parentheses, indicate the command line option values |
| to use for selecting the different compilers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, the JDK compiler is faster for small CIF models, while the Eclipse |
| compiler is faster for larger CIF models. By default, the JDK compiler is |
| used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <em>Java Compiler</em> option has no effect when simulating using a |
| <a href="#tools-cifsim-chapter-repeated-simulation">compiled code file</a> (e.g. a |
| <code>.cifcode</code> file) for repeated simulations, or when |
| <a href="#tools-cifsim-chapter-debug-gen-code">debugging generated code</a> by enabling |
| the <em>Load debug code</em> option (<em>Simulator</em> category).</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-simulation-miscellaneous-topics">Simulation miscellaneous topics</h4> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-complete-mode">Complete mode</h5> |
| <div class="paragraph"> |
| <p> |
| The CIF simulator calculates for each <a href="#tools-cifsim-traces-state">state</a> |
| the set of transitions that are possible from |
| that state. It is up to the <a href="#tools-cifsim-input-chapter-index">input component</a> |
| to choose one of those transitions, as the transition to take. Using the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input mode</a>, it is possible to |
| always choose the first transition that is possible.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In that situation, it is then a waste of resources to calculate the other |
| possible transitions. Using the |
| <b class="menuref">Complete mode</b> |
| option (<b class="menuref">Simulator</b>) |
| category), it is possible to enable complete mode. If |
| complete mode is enabled, the calculation of the possible transitions stops as |
| soon as one possible transition is found.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following values are available for the complete mode option:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Auto: disable if possible, enable otherwise</em></p> |
| <div class="paragraph"> |
| <p>Automatically chooses whether to enable or disable complete mode. If it is |
| allowed to disable complete mode, it will be disabled. Otherwise, complete |
| mode will be enabled.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>On: forced enabled</em></p> |
| <div class="paragraph"> |
| <p>Enables complete mode. All possible transitions will be calculated.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Off: forced disabled</em></p> |
| <div class="paragraph"> |
| <p>Disables complete mode. Only the first possible transitions will be |
| calculated.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Currently, it is only allowed to disable complete mode, if the |
| <a href="#tools-cifsim-input-chapter-automatic">automatic input mode</a> or |
| <a href="#tools-cifsim-input-svg-chapter-index">SVG input mode</a> is used, together with |
| always choosing the first possible transition.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-extfuncs">External user-defined functions</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF simulator supports external user-defined functions. Currently, the |
| following external languages are supported:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-chapter-extfuncs-java">Java</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-extfuncs-async">Asynchronous execution</h6> |
| <div class="paragraph"> |
| <p>By default, external user-defined functions are executed asynchronously. This |
| ensures that the simulation can be <a href="#tools-cifsim-chapter-termination">terminated</a> |
| during the execution of such a function. This is |
| useful if such functions take a long time to execute. It is also particularly |
| useful for external functions that never terminate, for instance because they |
| get stuck in a loop, often due to a bug.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| This asynchronous execution however, does lead to a performance penalty. To |
| get rid of this performance penalty, disable asynchronous execution, leading |
| to synchronous execution. Asynchronous execution can be disabled using the |
| <b class="menuref">External functions asynchronous execution</b> |
| option |
| (<b class="menuref">Simulator</b> |
| category).</p> |
| </div> |
| <div class="paragraph"> |
| <p>By disabling the asynchronous execution, the simulator can no longer be |
| terminated if it gets stuck executing an external user-defined function. If the |
| functions runs for a long time, the termination is postponed until the external |
| function finishes its execution.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cifsim-extfuncs-side-effects">Side effects</h6> |
| <div class="paragraph"> |
| <p>All user-defined functions in CIF are pure mathematical functions. They must |
| therefore be deterministic, and may not have side effects. For internal |
| user-defined functions, this is enforced. For external user-defined functions, |
| it is mostly impossible to check this constraint in an implementation, and the |
| responsibility for checking this is therefore delegated to the end user. |
| Practically, this means that for instance logging statements in functions, |
| while essentially side effects, may be permitted, as long as the function |
| returns the same value, if given the same arguments. This is essential for |
| correct simulation results, as the results of function calls may for instance |
| be cached by the simulator.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-value-semantics">Value semantics</h6> |
| <div class="paragraph"> |
| <p>The CIF simulator uses value semantics for the parameters and return values |
| of functions. That is, changes to the parameters of functions in external |
| user-defined functions are <em>not</em> reflected back to the CIF specification. |
| Furthermore, changes to the return values in the CIF simulator have no effect |
| on subsequent calls to external user-defined functions.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-extfuncs-java">External user-defined Java functions</h5> |
| <div class="paragraph"> |
| <p> |
| External user-defined Java functions allow the use of static Java methods from |
| CIF specifications. This page explains how to use such Java methods, how the |
| simulator loads and invokes them, what is allowed, etc. It explicitly does not |
| explain how to write or compile Java code.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-external-implementation-reference">External implementation reference</h6> |
| <div class="paragraph"> |
| <p>Consider the following examples of external user-defined Java function:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func real f1(real x): "java:java.lang.Math.expm1"; |
| |
| func int f2(bool x): "java:pkg.Cls.method|../some.jar;bin";</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Two external user-defined functions are given as examples. Both have a string |
| literal as external implementation reference. For Java functions, the string |
| literal must start with <code>java:</code>. Then the absolute name of the Java method |
| that is to be invoked is given. That is, the package name, class name, and |
| method name are given, separated by dots (<code>.</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Optionally, a Java class path may be given at the end, preceded by a bar |
| (<code>|</code>) character. The class path entries must be separated by semicolons |
| (<code>;</code>) regardless of the operating system. The class path entries are absolute |
| or relative local file system paths to Jar files or directories with Java class |
| files. Relative paths are resolved against the directory that contains the |
| CIF specification in which the external user-defined function is declared. Both |
| Linux/Mac path separators (<code>/</code>) and Windows path separators (<code>\</code>) may be |
| used in class path entries. However, <code>\</code> must be escaped as <code>\\</code> in CIF |
| string literals, and thus it is recommended to always use <code>/</code> as path |
| separator. A discussion of the Java class path concept is beyond the scope of |
| this documentation.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-types-and-values">Supported types and values</h6> |
| <div class="paragraph"> |
| <p>Not all CIF data types are supported for the parameters and return values of |
| external user-defined Java functions. The following table lists the allowed |
| CIF types, and their corresponding Java types.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF type</th> |
| <th class="tableblock halign-left valign-top">Java type</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.Boolean</code> / <code>boolean</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.Integer</code> / <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int[a..b]</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.Integer</code> / <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.Double</code> / <code>double</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>string</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.String</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.List<t></code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>set t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.List<t></code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>dict(k: v)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.Map<k, v></code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(t1, t2, ..., tn)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.List<java.lang.Object></code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Unless otherwise specified, the primitive Java types (<code>boolean</code>, <code>int</code>, |
| and <code>double</code>) can be used interchangeably with their class variants |
| (<code>java.lang.Boolean</code>, <code>java.lang.Integer</code>, and <code>java.lang.Double</code>). |
| For lists and sets, the element type recursively affects the type parameters of |
| the Java types. Similarly, for dictionaries, the key and value types affect |
| the type parameters of the Java <code>Map</code> type. Since Java doesn’t have tuples, |
| and there is no way in Java to define a type with a variable number of type |
| parameters, CIF tuples are passed to Java as a list of objects. It may be |
| assumed that such lists have the same number of elements as there are fields in |
| the original tuple, and that the elements have types that correspond to the |
| types of the field of the tuple. The following table shows a few examples:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF type</th> |
| <th class="tableblock halign-left valign-top">Java type</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>boolean</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.List<java.lang.Integer></code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>set tuple(int a, b)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.Set<java.util.List<java.lang.Object>></code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>For parameters, no <code>null</code> values are ever passed, not even as elements of |
| lists, etc. Furthermore, for <code>real</code> typed values, <code>NaN</code>, positive infinity, |
| and negative infinity are never passed along.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For return values, <code>null</code> values, as well as <code>NaN</code>, positive infinity, and |
| negative infinity are considered runtime errors. Furthermore, integer values |
| outside their CIF integer type range bounds are considered runtime errors as |
| well.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-method-resolution">Method resolution</h6> |
| <div class="paragraph"> |
| <p>The class as specified in the external implementation reference is loaded using |
| a Java class loader. By default, the system class loader is used. If additional |
| class path entries are specified in the external implementation reference, an |
| extended class loader is used that searches in the additional class path |
| entries before deferring to the system class loader. The class is loaded using |
| the |
| <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#name">binary name</a> |
| of the class.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The method that is resolved must be a static method. The access modifier of the |
| static method is irrelevant. That is, it doesn’t matter whether the method is |
| <code>private</code>, <code>protected</code>, <code>public</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The method is resolved in the Java Virtual Machine (JVM) that runs the |
| simulator. The method is resolved by name, and parameter types. The parameter |
| types only include the top level type. That is, for CIF type <code>list int</code>, the |
| Java type <code>java.util.List</code> is used as the type of the parameter. If more than |
| one method with the same parameter types is declared in the class, and one of |
| these methods has a return type that is more specific than any of the others, |
| that method is used. Otherwise one of the methods is chosen arbitrarily.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For parameters that have primitive Java types as their type, the primitive |
| types are used to resolve the method instead of their classes. In other words, |
| when resolving the method, or the proper overload of the method, <code>int</code> and |
| <code>java.lang.Integer</code> are considered incompatible.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF simulator employs lazy loading. That is, if the external Java |
| function is never called, it is also never loaded.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-method-invocation">Method invocation</h6> |
| <div class="paragraph"> |
| <p>The method is invoked in the Java Virtual Machine (JVM) that runs the |
| simulator, using reflection. By default, it is invoked |
| <a href="#tools-cifsim-extfuncs-async">asynchronously</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since the parameter types are not checked recursively when the method is |
| resolved, methods may fail to execute properly if the type signatures don’t |
| match exactly. Similarly, for the return type only the top level type is |
| checked. If a return value does not match the CIF type (wrong element type, |
| wrong tuple length, etc), simulation will fail with a runtime error.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Any exceptions that occur during execution of the Java method are caught by |
| the simulator. When the simulator catches such an exception, it will print the |
| Java stack trace of the exception to the console, and simulation will be |
| <a href="#tools-cifsim-chapter-termination">terminated</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-side-effects">Side effects</h6> |
| <div class="paragraph"> |
| <p>As all functions in CIF, external user-defined Java functions should not have |
| any <a href="#tools-cifsim-extfuncs-side-effects">side effects</a>. That is, if |
| called with the same arguments, it should return the same value each time. |
| More concretely, maintaining state information should be avoided, as should |
| file I/O, and reading from stdin.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Writing to stdout and stderr should not affect the result of the method. It |
| should however be avoided as well, as such writes are associated with the |
| streams of the Java Virtual Machine (JVM), and not the simulator. The output |
| will not end up on the Eclipse console of the simulator.</p> |
| </div> |
| <div class="paragraph"> |
| <p>By default, the Java methods are invoked <a href="#tools-cifsim-extfuncs-async">asynchronously</a>, |
| on a freshly created thread. That is, there |
| is no guarantee that an invocation uses the same thread as the previous |
| invocation. If static fields (class variables) are used to maintain state, this |
| may cause problems if thread safety is not ensured by the Java method. If |
| synchronous execution is used, all external function calls are invoked from the |
| simulation thread, and such thread safety issues should not be a problem.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You should assume that each external function is loaded using a different |
| class loader. As such, multiple Java methods from the same class, from the |
| same external library, may be loaded using different class loaders as |
| well. As such, shared static fields (class variables) of those classes can in |
| general not be shared by different external functions.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-profiling">Profiling</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF simulator has a |
| <b class="menuref">Profiling</b> |
| option (<b class="menuref">Simulator</b> |
| category). If the option is enabled, information about the number of |
| transitions taken per second, is printed to the console. Enabling profiling |
| disables most other types of console |
| <a href="#tools-cifsim-output-chapter-index">output</a>. By default, profiling is disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The profiling output looks somewhat like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">750431.42 transitions/second |
| 640589.87 transitions/second |
| 890939.01 transitions/second |
| 887228.57 transitions/second |
| 890143.25 transitions/second |
| 893674.44 transitions/second |
| 891812.69 transitions/second</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-distr-seeds">Stochastic distributions and seeds</h5> |
| <div class="paragraph"> |
| <p> |
| |
| <a href="#tut-stochastics-chapter-intro">Stochastics</a> can be used to model |
| randomness in CIF models. The CIF simulator exhibits |
| <a href="#tut-stochastics-chapter-pseudo-randomness">pseudo-randomness</a>. This page |
| explains how to influence that pseudo-randomness.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The randomness of the stochastic distributions is implemented in the CIF |
| simulator using |
| <a href="http://en.wikipedia.org/wiki/Pseudorandom_number_generator">pseudorandom number generators</a> |
| (PRNGs). The PRNG used is the |
| <a href="http://en.wikipedia.org/wiki/Mersenne_twister">Mersenne Twister</a>. |
| The sequences of |
| random numbers that are generated by the MT are not truly random. They are |
| pseudorandom, as they start to repeat after some time. The Mersenne Twister |
| however, has a very long <em>period</em> of 2<sup>19937</sup> - 1 numbers.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since the sequence of generated random numbers is always the same, the only |
| way to vary it, is to use a different starting place. The starting place is |
| determined by the initial |
| <a href="http://en.wikipedia.org/wiki/Random_seed">seed</a>, |
| which can be configured through the |
| <b class="menuref">Initial seed for stochastic distributions</b> |
| option (<b class="menuref">Simulator</b> |
| category). If specified, it must |
| be a value in the range [1 .. 2<sup>30</sup>]. If it is not specified, a random |
| initial seed in that range is chosen by the simulator. If a random initial seed |
| is chosen, and it is used, it is <a href="#tools-cifsim-output-normal-seeds">printed</a> to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The initial seed as provided by the option, is used for the first stochastic |
| distribution that is created. Each subsequent distribution uses the next |
| available seed. That is, if you specify an initial seed of 5, then the first |
| distribution is created with an initial seed of 5, the next one uses 6, the |
| third one uses 7, etc. The initial seeds are kept in the range |
| [1 .. 2<sup>30</sup>]. After seed 2<sup>30</sup>, 1 is used as seed, then 2 is used as seed, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulating the same specification multiple times, using the same initial seed, |
| results in the same samples. Therefore, using a fixed seed can make your |
| simulation deterministic, even though you use stochastic distributions to |
| introduce randomness into your specification.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-simulation-developer-topics">Simulation developer topics</h4> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-max-time-point-tol">Maximum time point tolerance</h5> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="admonitionblock warning"> |
| <table> |
| <tr> |
| <td class="icon"> |
| <i class="fa icon-warning" title="Warning"></i> |
| </td> |
| <td class="content"> |
| This page is primarily intended for the developers of the CIF simulator, |
| and not its end users. |
| </td> |
| </tr> |
| </table> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF simulator internally often queries the trajectories computed by the |
| <a href="#tools-cifsim-solver-chapter-index">ODE solver</a>. Due to the limited precision |
| of binary floating point number representations, requests of time points for |
| which no exact match is present in the trajectories, but for which a very close |
| match is present, are allowed. The simulator compensates for these small |
| deviations, to avoid accumulation of such deviations.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| The simulator uses the value of the |
| <b class="menuref">Maximum time point tolerance</b> |
| option (<b class="menuref">Simulation</b> |
| category) to determine whether two time points |
| are close enough to each other to constitute a match. The tolerance is given in |
| <a href="http://en.wikipedia.org/wiki/Unit_in_the_last_place">ulps</a> |
| (<em>units in the |
| last place</em>, or <em>units of least precision</em>). One ulp is the difference |
| between two subsequent floating point numbers, for the limited precision |
| binary floating point number representation used by the simulator. That is, two |
| floating point numbers are one ulp away from each other, if there is no other |
| floating point number between them, that can be represented using the floating |
| point number representation used by the simulator. Since an ulp increases as |
| the floating point numbers increase, the tolerance is thus relative to the |
| values of the time points.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The tolerance values chosen using the option must be in the range |
| [1 .. 2<sup>30</sup>]. The default tolerance is 2<sup>10</sup> (= 1024) ulps. The default |
| tolerance should suffice, but if it doesn’t, you may |
| be presented with an error like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">ERROR: Simulation resulted in a runtime error, for state: time=0.0, x=1.0. |
| CAUSE: Requested time point "1.6000000000000005" is "2.0" ulps (1 ulp = 2.220446049250313e-16) away from the closest time point in the trajectories "1.6", which is farther away than the maximum tolerance of "1" ulps. You can try increasing the value of the maximum time point tolerance option. Please also contact the development team.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If you get such an error, you can try to increase the tolerance using the |
| <b class="menuref">Maximum time point tolerance</b> |
| option, in order to be able to |
| continue your simulation. However, as this shouldn’t actually happen, you |
| should also contact the development team, who will then figure out why the |
| default tolerance doesn’t suffice for your model.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-debug-gen-code">Debugging generated code</h5> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="admonitionblock warning"> |
| <table> |
| <tr> |
| <td class="icon"> |
| <i class="fa icon-warning" title="Warning"></i> |
| </td> |
| <td class="content"> |
| This page is primarily intended for the developers of the CIF simulator, and not its end users. |
| </td> |
| </tr> |
| </table> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF simulator generates highly optimized code for the specification, to |
| speed up the simulation. By enabling the |
| <b class="menuref">Debug the generated code (by writing it to disk)</b> |
| <a href="#tools-cifsim-output-chapter-debug">debugging output</a>, |
| the generated code can be written to disk, for further debugging.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-output-directory">Output directory</h6> |
| <div class="paragraph"> |
| <p>If the simulation is performed from within Eclipse, and a project named |
| <code>org.eclipse.escet.cif.simulator.debug</code> exists, is not closed, and has a <code>src</code> |
| directory, the generated code will be written to that <code>src</code> directory. |
| Otherwise, the generated code will be written to the directory containing the |
| input specification file.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Regardless, the code is also always written to a <code>cifcode</code> |
| sub-directory. If this sub-directory does not yet exist, it is created. If it |
| already exists, all existing <code>.java</code> files are removed from the |
| sub-directory first, before the newly generated code is written.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-written-files">Written files</h6> |
| <div class="paragraph"> |
| <p>The generated code consists of Java files only. This results in several |
| <code>.java</code> files being written to the <code>cifcode</code> directory.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Additionally, an Eclipse launch configuration file (<code>_cifsim_debug.launch</code>) |
| is written. This launch configuration can be used to reproduce the simulation |
| implemented by the generated code. The launch configuration |
| reproduces the simulation options that were used, and always shows the option |
| dialog. The working directory for the simulation performed via the generated |
| launch configuration is the same working directory as the original simulation. |
| This allows additional files, such as configuration files, to be found.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-how-to-use">How to use</h6> |
| <div class="paragraph"> |
| <p>To use this feature, follow these steps:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Import all CIF related source projects into your Eclipse workspace.</p> |
| </li> |
| <li> |
| <p>Make sure your workspace is automatically rebuilt, by enabling the |
| <b class="menuref">Build Automatically</b> |
| option in the |
| <b class="menuref">Project</b> |
| menu.</p> |
| </li> |
| <li> |
| <p>Start a sub-Eclipse application, by right clicking on any plug-in project in |
| the workspace, and choosing <span class="menuseq"><b class="menu">Run as</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Eclipse Application</b></span> |
| or <span class="menuseq"><b class="menu">Debug as</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Eclipse Application</b></span>.</p> |
| </li> |
| <li> |
| <p>In the sub-Eclipse that opens, make sure the CIF specification (the <code>.cif</code> |
| file) that you like to simulate is available in the workspace.</p> |
| </li> |
| <li> |
| <p>In the sub-Eclipse, import the <code>org.eclipse.escet.cif.simulator.debug</code> source |
| project.</p> |
| </li> |
| <li> |
| <p>Simulate the CIF specification, and make sure you enable the |
| <b class="menuref">Debug the generated code</b> |
| option.</p> |
| </li> |
| <li> |
| <p>Continue simulation, if desired.</p> |
| </li> |
| <li> |
| <p>Once the simulation has terminated, switch back to the main Eclipse.</p> |
| </li> |
| <li> |
| <p>Refresh the <code>org.eclipse.escet.cif.simulator.debug</code> project.</p> |
| </li> |
| <li> |
| <p>Set breakpoints in the generated Java code, or in the simulator code, as |
| desired.</p> |
| </li> |
| <li> |
| <p>Right click the launch configuration in the <code>src/cifcode</code> directory, and |
| choose <span class="menuseq"><b class="menu">Debug as</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">_cifsim_debug</b></span>.</p> |
| </li> |
| <li> |
| <p>Debug the simulation, with the generated code, as you would any Java program.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-starting-the-simulator-with-generated-code">Starting the simulator with generated code</h6> |
| <div class="paragraph"> |
| <p>The launch configuration that is written to disk with the generated code, uses |
| the |
| <b class="menuref">Load debug code</b> |
| option (<b class="menuref">Simulator</b> category). Using |
| this option, the classpath (directory) where the already generated code is |
| located, is specified. By specifying it, the simulator knows from where to load |
| it.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulations not started from the generated launch configuration, generally |
| don’t use this option. They load the input specification, validate it, generate |
| fresh code, and compile the code in-memory, or use |
| <a href="#tools-cifsim-repeated-sim-compile-once">compiled code files</a></p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulations using the generated code ignore all options related to |
| <a href="#tools-cifsim-chapter-repeated-simulation">repeated simulations</a>. That is, the |
| <em>Load debug code</em> option takes priority over the <em>Compile only</em> option |
| (<em>Compiler</em> category), and simulating with |
| <a href="#tools-cifsim-repeated-sim-compile-once">compiled code files</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A warning is printed to the console if the generated code was generated with |
| a different version of the simulator than the one used to simulate it. Ignoring |
| the warning may lead to unexpected simulation results, or even simulator |
| crashes.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cifsim-chapter-test-mode">Test mode</h5> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="admonitionblock warning"> |
| <table> |
| <tr> |
| <td class="icon"> |
| <i class="fa icon-warning" title="Warning"></i> |
| </td> |
| <td class="content"> |
| This page is primarily intended for the developers of the CIF simulator, |
| and not its end users. |
| </td> |
| </tr> |
| </table> |
| </div> |
| <div class="paragraph"> |
| <p>In order to be able to perform automated testing, the |
| <b class="menuref">Test mode</b> |
| option (<b class="menuref">Output</b> |
| category) can be used. This option has the following |
| effect:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The visual interfaces for all |
| <a href="#tools-cifsim-output-chapter-index">output components</a> (such as visualizers) |
| are disabled.</p> |
| </li> |
| <li> |
| <p>The user is no longer asked to |
| <a href="#tools-cifsim-termination-confirm">confirm termination</a> of the |
| simulator, if the the |
| <b class="menuref">Ask to confirm simulator termination</b> |
| option (<b class="menuref">Simulator</b> |
| category) is configured to let the simulator |
| decide whether to ask the user for confirmation or terminate automatically. |
| By not asking for user input at the console, the automated test set can be |
| fully automatically executed.</p> |
| </li> |
| <li> |
| <p>It is allowed to perform <a href="#tools-cifsim-output-chapter-realtime">real-time</a> |
| simulation without using any |
| <a href="#tools-cifsim-output-realtime-outcomp">real-time output components</a>, |
| allowing testing of the real-time functionality in the automated test set.</p> |
| </li> |
| <li> |
| <p>All <a href="#tools-cifsim-output-chapter-realtime">real-time delays</a> are skipped. By |
| not performing unnecessary real-time delays, the automated test set executes |
| as fast as possible.</p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-index">SVG visualization</a> operates in |
| synchronous mode, rather than asynchronous mode. This ensures that debug |
| output becomes synchronous as well, and we thus get consistent output for our |
| test cases. This is not only useful for automated testing, but also for |
| debugging.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-verification-tools">Verification tools</h3> |
| <div class="sect3"> |
| <h4 id="tools-chapter-cif2mcrl2">CIF to mCRL2 transformer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF to mCRL2 transformer is used to convert a CIF specification to a |
| mCRL2 specification. |
| <a href="http://www.mcrl2.org/">mCRL2</a> |
| is a tool for verifying properties of the model.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-4">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF verification tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to mCRL2…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF verification tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to mCRL2…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2mcrl2</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2mcrl2</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2mcrl2-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative file system path to the input |
| CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Instance tree definition</em>: mCRL2 uses a tree of processes which you can |
| specify manually here. If not specified, it takes the default solution, |
| which first merges all CIF automata (one at a time), and on top of that, the |
| variable processes of the shared variables (also one at a time). |
| How to define your own tree is explained in the |
| <a href="#tools-cif2mcrl2-instancetree-syntax">instantiation tree syntax</a> Section.</p> |
| </li> |
| <li> |
| <p><em>Enable debug output</em>: The transformer derives information about used and |
| available variables in the instantiation tree, and uses that information to |
| generate the mCRL2 action operations at every level. By enabling this |
| option, this information is also written to an output file for further |
| external analysis. By default, the information is written in a file with the |
| same name as the input file, except first the <code>.cif</code> extension is removed |
| (if present), and a <code>_dbg.txt</code> extension is appended. The name of the |
| output file can be changed with the <em>Debug output file path</em> option. Setting |
| the latter option enables this option.</p> |
| </li> |
| <li> |
| <p><em>Debug output file path</em>: The absolute or relative file system path to use |
| for writing derived information about used and available variables at every |
| level in the instantiation tree. Setting this option changes the debug |
| output file path to the given path. It also enables the <em>Enable debug |
| output</em> option.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative file system path for writing |
| the generated mCRL2 output file. By default, the output file path is the |
| same as the input file path, but with the <code>.cif</code> extension removed (if it |
| exists), and the <code>.mcrl2</code> extension added. By setting this option, the |
| default is overridden by the given value.</p> |
| </li> |
| <li> |
| <p><em>Generate 'value' actions</em>: To query the value of variable <code>x</code>, |
| a <code>value_x</code> action can be used. By default, such actions are generated for |
| every variable in the system. Using this option, you can define precisely |
| which variables should have such an action. See the |
| <a href="#cif2mcrl2-value-select">Generation of 'value' actions</a> Section for more details.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-4">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The CIF to mCRL2 transformer supports a subset of CIF specifications. The |
| following restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The transformer ignores the supervisory kind of the automata.</p> |
| </li> |
| <li> |
| <p>Algebraic variables are not supported.</p> |
| </li> |
| <li> |
| <p>Continuous variables are not supported.</p> |
| </li> |
| <li> |
| <p>Equations are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates are not supported, except for initialization |
| predicates in a location.</p> |
| </li> |
| <li> |
| <p>Invariants are not supported.</p> |
| </li> |
| <li> |
| <p>Marker predicates are ignored.</p> |
| </li> |
| <li> |
| <p>Discrete variables must have type <code>bool</code> or <code>int</code>. The latter may have |
| a range.</p> |
| </li> |
| <li> |
| <p>Multiple potential initial values are not supported.</p> |
| </li> |
| <li> |
| <p>Initial value must be a constant.</p> |
| </li> |
| <li> |
| <p>There must be at least one automaton.</p> |
| </li> |
| <li> |
| <p>The transformation translates the range of integer variables if used, but it |
| does not enforce the maximum and minimum integer value of CIF.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In automata, there are a number of extra conditions:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The <code>initial</code> expression in locations must be constant.</p> |
| </li> |
| <li> |
| <p>There must be a single initial location in each automaton.</p> |
| </li> |
| <li> |
| <p>Conditional updates are not supported, only assignment updates are allowed.</p> |
| </li> |
| <li> |
| <p>Multi-assignments are not supported.</p> |
| </li> |
| <li> |
| <p>Channels are not supported.</p> |
| </li> |
| <li> |
| <p>The <code>tau</code> event is not supported.</p> |
| </li> |
| <li> |
| <p>Urgency of locations and edges is ignored.</p> |
| </li> |
| <li> |
| <p>Location references are not supported.</p> |
| </li> |
| <li> |
| <p>All expressions and sub-expressions must be of type <code>bool</code> or <code>int</code>. The |
| latter may have a range.</p> |
| </li> |
| <li> |
| <p>Boolean constants, discrete variables, and operators <code>and</code>, <code>or</code>, |
| <code>==</code>, <code>>=</code>, <code>></code>, <code><=</code>, <code><</code>, <code>!=</code>, and <code>not</code> are allowed.</p> |
| </li> |
| <li> |
| <p>Integer constants, discrete variables, binary operators <code>+</code>, <code>*</code>, <code>-</code>, |
| and unary operators <code>-</code> and <code>+</code> are allowed.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>However, some of these limitations are resolved by preprocessing of the |
| specification, as explained in the next section.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-4">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-alg-vars">Eliminate algebraic variables</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-consts">Eliminate constants</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-monitors">Eliminate monitors</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="cif2mcrl2-value-select">Generation of 'value' actions</h5> |
| <div class="paragraph"> |
| <p>The CIF to mCRL2 transformer generates a <code>value</code> action for each variable by |
| default. In some cases, this may not be wanted. Variables that never have to |
| be queried for their value do not need such an action. Having such an action |
| available anyway increases the amount of work that has to be done by the mCRL2 |
| tool. To eliminate these unneeded <code>value</code> actions, the CIF to mCRL2 |
| transformer has the <em>Generate 'value' actions</em> option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The option takes a comma separated list of variable patterns. Each pattern |
| can add or remove variables. If the pattern starts with a <code>+</code> character, |
| variables are added. If the pattern starts with a <code>-</code> character, variables |
| are removed. If the pattern start neither with a <code>+</code> nor with a <code>-</code> |
| character, variables are added. The main part of each pattern is the name of |
| the variable to add or remove. In addition, you can use the <code>*</code> character |
| as a shorthand for 'zero or more arbitrary characters', allowing you to write |
| abbreviations, and match several variables at the same time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For example, assume existence of the following variables in a CIF model:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>A.p12 A.q2 A.z B.x B.y1 B.y2 B.z C.q</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Below a number of example option values, and what variables they select from |
| the above list.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The option value <code>B.x,+A.z</code> selects variables <code>B.x</code> and <code>A.z</code>.</p> |
| </li> |
| <li> |
| <p>The option value <code>+*1</code> matches all variables that end with a <code>1</code>, which |
| is variable <code>B.y1</code> only (Variable <code>A.p12</code> does have a <code>1</code> in it, but |
| not at the end.)</p> |
| </li> |
| <li> |
| <p>The option value <code>+*1*</code> matches all variables with a <code>1</code> at any |
| position. This matches both <code>A.p12</code> and <code>B.y1</code>.</p> |
| </li> |
| <li> |
| <p>The option value <code>+*,-B.*</code> selects all variables, except those in |
| automaton <code>B</code>. (<code>*</code> adds all variables, then <code>-B.*</code> removes all |
| variables that start with <code>B.</code>, that is all variables in automaton <code>B</code>.)</p> |
| </li> |
| <li> |
| <p>The option value <code>-*</code> removes all <code>value</code> actions, since the pattern |
| removes all variables.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2mcrl2-instancetree-syntax">Syntax of the instance tree</h5> |
| <div class="paragraph"> |
| <p>In mCRL2, a behavior process is required for every automaton in the input, and |
| a variable process is needed for every variable used (read or written) by two |
| or more automata. In addition, it is allowed to have a variable process for |
| variables that are used in one automaton only (that is, a local variable of |
| the automaton).</p> |
| </div> |
| <div class="paragraph"> |
| <p>All these processes must be instantiated using the parallel composition |
| operator. For larger specifications, the naive solution of instantiating all |
| processes together in one level fails due to having too many allowed |
| combinations of actions for the mCRL2 tool to handle.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A different solution is to instantiate smaller groups of processes at a time, |
| and then use these groups again in other instantiations. Instantiation happens |
| in multiple levels in this case, leading to a tree of process instantiations. |
| At each level, the set of allowed actions is restricted by adding action |
| operators. This results in a large reduction of the number of possible |
| combinations of actions that need to be explored by the mCRL2 tool. Fewer |
| combinations of actions in turn leads to enabling larger specifications to be |
| verified.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Which processes and groups are taken together at each level in the tree has a |
| large impact on feasibility. The CIF to mCRL2 transformer has a default |
| scheme, where pairs of one group and one behavior process are taken together |
| at each level (except at the bottom, where two behavior processes are merged |
| instead). On top of that tree, pairs of a group and a variable process are |
| taken together.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF to mCRL2 transformer does not perform analysis to decide how processes |
| and variables should combined. In many cases this provides a working solution. |
| For some specifications however, you may want to have more influence in the |
| order of grouping. For this reason, the <em>Instance tree definition</em> option |
| exists. It allows you to define which processes should be taken together at |
| each level in the instantiation tree.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The current implementation has limits with respect to ordering. Automata |
| processes must be merged first (but the number of levels and the order of |
| combining is free), and then variables must be added one at a time (but which |
| variable to use at each level is free).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The option expects absolute names of all automata in the specification and |
| absolute names of all discrete variables used in two more automata, separated |
| by white space or commas. In addition you may add the absolute names of |
| variables used in only one automaton. For each element mentioned, a process is |
| created in mCRL2. Variables used in one automaton that are not mentioned, |
| become local variables of the behavior process of the automaton that uses the |
| variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Processes for the mentioned CIF elements are instantiated. Sub-groups of |
| processes are written by surrounding them with parentheses. For example:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>( ( A B C ) A.x ) B.y</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>takes automata <code>A</code>, <code>B</code>, <code>C</code> together. One level higher, variable |
| <code>A.x</code> is added, and finally variable <code>B.y</code> is added at the highest level. |
| Another order is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>( ( ( A B ) C ) B.y ) A.x</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>First processes <code>A</code> and <code>B</code> are combined, then process <code>C</code> is added, and |
| finally variables <code>B.y</code> and <code>A.x</code> at the top-most two levels.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-debug-output">Debug output</h5> |
| <div class="paragraph"> |
| <p>The transformer analyzes use of the variables by each automaton, and computes |
| variable usage and availability of the variables at each level in the |
| instantiation tree. This information is written to a file with debug output by |
| enabling the <em>Enable debug output</em> option. As an example, consider the |
| following artificial CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event a, b, c; |
| |
| automaton P: |
| disc int[0..10] x = 0; |
| disc int[-5..5] zero = 0; |
| |
| location p1: |
| initial; |
| edge a do x := x + 1 goto p2; |
| |
| location p2: |
| edge c when Q.y != 0 goto p1; |
| edge a do x := 1 goto p1; |
| end |
| |
| automaton Q: |
| disc int[0..1] y = 1; |
| |
| location q1: |
| initial; |
| edge a when y = 1 goto q2; |
| |
| location q2: |
| edge b when y = 1 and P.x < 8 and P.zero = 0 goto q1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This specification has two automata <code>P</code> and <code>Q</code>, and two shared variables |
| <code>P.x</code> and <code>Q.y</code>. The ranges of the variables are important, mCRL2 |
| considers the integer type unbounded, depending on your CIF file, without |
| giving upper and lower bounds for the variables, you may end up in the |
| situation that mCRL2 tries every single value of its infinite integer type, |
| which takes a very long time!</p> |
| </div> |
| <div class="paragraph"> |
| <p>Variable <code>zero</code> is not shared, only automaton <code>Q</code> uses it. The transformer |
| moves it to the <code>Q</code> process. Normally however, you would use a constant |
| instead of a variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The instance tree used in the transformation is <code>( ( P Q ) P.x ) Q.y</code>. The |
| debug output for <code>P</code> is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1.1.1.1 |
| |
| Variable use by behavior processes ordered by event: |
| a: |
| P.x read:SOMETIMES write:ALWAYS |
| c: |
| Q.y read:ALWAYS write:NEVER</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Automaton <code>P</code> has one <code>c</code> edge, which checks the value of <code>Q.y</code> but it |
| does not change its value. It has two <code>a</code> edges, only the <code>a</code> edge in |
| location <code>p1</code> reads <code>P.x</code> (to compute <code>x + 1</code>). Both edges assign a new |
| value to <code>P.x</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In a similar way, the node information for automaton <code>Q</code> is computed. The |
| result is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1.1.1.2 |
| |
| Variable use by behavior processes ordered by event: |
| a: |
| Q.y read:ALWAYS write:NEVER |
| b: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:ALWAYS write:NEVER</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The automaton only checks values rather than writing them. As you can see, |
| variable <code>P.x</code> is not mentioned with event <code>a</code>, since there is no edge in |
| the automaton with event <code>a</code> that accesses variable <code>P.x</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The node that merges both automata, i.e. <code>( P Q )</code>, has the following |
| formation:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1.1.1 |
| |
| Variable use by behavior processes ordered by event: |
| a: |
| P.x read:SOMETIMES write:ALWAYS |
| Q.y read:ALWAYS write:NEVER |
| c: |
| Q.y read:ALWAYS write:NEVER |
| b: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:ALWAYS write:NEVER |
| |
| Children: |
| node 1.1.1.1 |
| node 1.1.1.2</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Variable use by each event is simply merged. In this example there is no |
| overlap, but that works as you would expect, <code>SOMETIMES</code> overrides |
| <code>NEVER</code>, and <code>ALWAYS</code> overrides <code>SOMETIMES</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The node for variable process for <code>P.x</code> only provides a variable:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1.1.2 |
| |
| Available variable processes: |
| P.x</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The output states that variable <code>P.x</code> is available here.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At <code>( P Q ) P.x</code> node, the merge of the variable <code>P.x</code> with the two |
| automata, this results in:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1.1 |
| |
| Available variable processes: |
| P.x |
| |
| Variable use by behavior processes ordered by event: |
| a: |
| P.x read:SOMETIMES write:ALWAYS |
| Q.y read:ALWAYS write:NEVER |
| c: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:NEVER write:NEVER |
| b: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:ALWAYS write:NEVER |
| |
| Children: |
| node 1.1.1 |
| node 1.1.2</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this node, variable <code>P.x</code> is also available. The variable process does |
| not perform events, so the event variable table of node <code>1.1.1</code> is copied. |
| The only exception is the additional line <code>P.x</code> for event <code>c</code>. The reason |
| for this line is that while <code>( P Q )</code> may not use <code>P.x</code> in combination |
| with event <code>c</code>, other automata higher up in the tree may still need that |
| variable. (In a future version of the transformer tool, it may be detected |
| that such use never happens, and there is no need to add the line here.)</p> |
| </div> |
| <div class="paragraph"> |
| <p>Node <code>1.2</code> is the variable process of <code>Q.y</code>. It looks the same as node |
| <code>1.1.2</code>, except for the name of the variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Finally the top-node that merges <code>( P Q ) P.x</code> with <code>Q.y</code>, bringing |
| everything together, looks like:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>=============================================================== |
| Node 1 |
| |
| Available variable processes: |
| P.x |
| Q.y |
| |
| Variable use by behavior processes ordered by event: |
| a: |
| P.x read:SOMETIMES write:ALWAYS |
| Q.y read:ALWAYS write:NEVER |
| c: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:NEVER write:NEVER |
| b: |
| Q.y read:ALWAYS write:NEVER |
| P.x read:ALWAYS write:NEVER |
| |
| Children: |
| node 1.1 |
| node 1.2</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>Q.y</code> variable is now also available. The event variable table is again |
| copied. Since all events already used variable <code>Q.y</code> no additional lines |
| were added.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-output-of-the-transformation">Output of the transformation</h5> |
| <div class="paragraph"> |
| <p>A variable process in mCRL2 handles shared access to a variable. For variable |
| <code>P.x</code> in the above example it looks like:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>act value_x, vread_x, vwrite_x, sync_x, aread_x, awrite_x : Int; |
| |
| proc VarProc_x(v:Int) = |
| value_x(v) . VarProc_x(v) + |
| vread_x(v) . VarProc_x(v) + |
| sum m:Int . ((m >= 0) && (m <= 10)) -> vwrite_x(m) . VarProc_x(m) + |
| sum m:Int . ((m >= 0) && (m <= 10)) -> vread_x(v) | vwrite_x(m) . VarProc_x(m);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The name of the actions all end with the name of the variable. If the CIF |
| specification has two or more variables with the same name, a number gets |
| appended to make each variable unique in mCRL2.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A behavior process is generated for each automaton instance. Like the |
| variables, the name of the automaton is used in the output. If there are |
| name conflicts, a number is appended to make it unique. The process is |
| the same list of edges of the original CIF automaton, with added read and |
| write actions for synchronizing with the variable processes:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>sort LocSort_P = struct loc_P_p1 | loc_P_p2; |
| |
| proc BehProc_P(Locvar_P : LocSort_P) = |
| sum x : Int . ((x >= 0) && (x <= 10) && (Locvar_P == loc_P_p1)) -> a | aread_x(x) | awrite_x((x + 1)) . BehProc_P(loc_P_p2) + |
| sum y : Int . ((y >= 0) && (y <= 1) && (Locvar_P == loc_P_p2) && (y != 0)) -> c | aread_y(y) . BehProc_P(loc_P_p1) + |
| (Locvar_P == loc_P_p2) -> a | awrite_x(1) . BehProc_P(loc_P_p1);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Locations are encoded in a <code>struct</code> and variable read and write actions are |
| added as needed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The instantiation tree is dominated by the action operators needed for |
| synchronizing and restricting actions. The <code>value_...</code> actions are allowed |
| up the to top level node, to give access to variable values in the |
| verification. This leads to:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>act a, renamed_a, c, renamed_c, b, renamed_b; |
| |
| init block({aread_y, awrite_y, vread_y, vwrite_y}, |
| hide({sync_y}, |
| comm({aread_y | vread_y -> sync_y, |
| awrite_y | vwrite_y -> sync_y}, |
| ( |
| block({aread_x, awrite_x, vread_x, vwrite_x}, |
| hide({sync_x}, |
| comm({aread_x | vread_x -> sync_x, |
| awrite_x | vwrite_x -> sync_x}, |
| ( |
| allow({value_zero, |
| a | awrite_x | aread_y, |
| a | awrite_x | aread_x | aread_y, |
| c | aread_y, |
| b | aread_y | aread_x}, |
| rename({renamed_a -> a}, |
| block({a}, |
| comm({a | a -> renamed_a}, |
| ( |
| BehProc_P(loc_P_p1) |
| || |
| BehProc_Q(loc_Q_q1, 0) |
| ))))) |
| || |
| VarProc_x(0) |
| )))) |
| || |
| VarProc_y(1) |
| ))));</code></pre> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-cif2uppaal">CIF to UPPAAL transformer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF to UPPAAL transformer can be used to transform CIF specifications |
| to UPPAAL systems (<code>*.xml</code> files). |
| <a href="http://www.uppaal.org/">UPPAAL</a> |
| is a tool modeling, validation, and verification of networks of timed automata with |
| variables. The transformer only transforms untimed CIF specifications.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-5">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF verification tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to UPPAAL…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF verification tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Convert CIF to UPPAAL…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2uppaal</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2uppaal</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-options-14">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative local file system path to the |
| output UPPAAL file. If not specified, defaults to the input file path, where |
| the <code>.cif</code> file extension is removed (if present), and a <code>.xml</code> file |
| extension is added.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-5">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The CIF to UPPAAL transformer supports a subset of CIF specifications. The |
| following restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Specifications without automata are not supported.</p> |
| </li> |
| <li> |
| <p>Channels (events with data types) are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in components are not supported.</p> |
| </li> |
| <li> |
| <p>Automata that do not have exactly one initial location are not supported.</p> |
| </li> |
| <li> |
| <p>Locations with initialization predicates that are too complex to evaluate |
| statically, are not supported. That is, those predicates must essentially be |
| be constant. For instance, <code>true</code> and <code>true or false</code> are supported, as |
| is <code>c</code> if <code>c</code> is a constant. However, <code>v => c</code> with <code>v</code> a discrete |
| variable that can initially have several different values, is not supported.</p> |
| </li> |
| <li> |
| <p>Discrete variables with multiple potential initial values are not supported.</p> |
| </li> |
| <li> |
| <p>Discrete variables with initial values that are too complex to evaluate |
| statically, are not supported. That is, their initial values must essentially |
| be constant. For instance, <code>1 + 1</code> and <code>2 * 5</code> are supported, as is |
| <code>c + 1</code> if <code>c</code> is a constant. However, <code>v * 2</code> with <code>v</code> a discrete |
| variable that can initially have several different values, is not supported.</p> |
| </li> |
| <li> |
| <p>Enumerations are not supported.</p> |
| </li> |
| <li> |
| <p>Continuous variables are not supported.</p> |
| </li> |
| <li> |
| <p>Algebraic variables are not supported.</p> |
| </li> |
| <li> |
| <p>Input variables are not supported.</p> |
| </li> |
| <li> |
| <p>User-defined functions are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent edges are not supported.</p> |
| </li> |
| <li> |
| <p>Multi-assignments on edges (such as <code>do (x, y) := (1, 2)</code>) are not |
| supported. However, it is allowed to use multiple assignments on an edge |
| (such as <code>do x := 1, y := 2</code>).</p> |
| </li> |
| <li> |
| <p>Partial variable assignments (such as <code>do x[0] := 5</code>) are not supported.</p> |
| </li> |
| <li> |
| <p>Conditional updates (<code>if</code> updates) on edges (such as |
| <code>do if b: x := 5 end</code>) are not supported.</p> |
| </li> |
| <li> |
| <p>Only the following data types are supported: boolean types and integer (both |
| with a range and without a range).</p> |
| </li> |
| <li> |
| <p>Only the following expressions are supported: boolean literal values |
| (<code>true</code> and <code>false</code>), integer literal values, binary expressions |
| (partially, see below), unary expressions (partially, see below), casts that |
| don’t change the type, <code>if</code> expressions, and references to constants, |
| discrete variables, and locations.</p> |
| </li> |
| <li> |
| <p>Only the following binary operators are supported: logical equivalence |
| (<code><=></code>), logical implication (<code>=></code>), logical conjunction (<code>and</code> on |
| boolean operands), logical disjunction (<code>or</code> on boolean operands), addition |
| (<code>+</code>) on integer operands, subtraction (<code>-</code>) on integer operands, |
| multiplication (<code>*</code>) on integer operands, integer division (<code>div</code>), |
| integer modulus (<code>mod</code>), equality (<code>=</code>) on integer operands, inequality |
| (<code>!=</code>) on integer operands, less than (<code><</code>) on integer operands, less |
| than or equal to (<code><=</code>) on integer operands, greater than (<code>></code>) on |
| integer operands, and greater than or equal to (<code>>=</code>) on integer operands.</p> |
| </li> |
| <li> |
| <p>Only the following unary operators are supported: logical inverse (<code>not</code>), |
| negation (<code>-</code>) on an integer operand, and plus (<code>+</code>) on an integer |
| operand.</p> |
| </li> |
| <li> |
| <p>Only state invariants are supported. State/event exclusion invariants are |
| not supported. To allow state/event exclusion invariants to be used in the |
| input, manually eliminate them first using the |
| <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> CIF to CIF transformation.</p> |
| </li> |
| <li> |
| <p>The controllability of events is ignored.</p> |
| </li> |
| <li> |
| <p>The supervisory kinds of automata are ignored.</p> |
| </li> |
| <li> |
| <p>The supervisory kinds of invariants are ignored.</p> |
| </li> |
| <li> |
| <p>Marker predicates are ignored.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-5">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-tau-event">Eliminate <code>tau</code> event</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-monitors">Eliminate monitors</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-transformation-result-2">Transformation result</h5> |
| <div class="paragraph"> |
| <p>CIF features synchronizing events, while UPPAAL only supports channels. A |
| <code>SendAut</code> automaton/template is added to the UPPAAL system to ensure proper |
| event synchronization. The UPPAAL template has a single location, and self |
| loops for every event in the CIF specification. The guards of the self loops |
| express the conditions under which the events are globally enabled (guard wise) |
| in the CIF specification. Every CIF event is a broadcast channel in UPPAAL. If |
| the self loop is enabled (guard wise), the <code>SendAut</code> template broadcasts over |
| the channel. All the other templates (for the CIF automata) receive the event. |
| They can actually receive, as the guard of the self loop ensures that. Together |
| the <code>SendAut</code> self loops and the receive edges form the synchronization.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As the <code>SendAut</code> template needs to refer to locations of the other templates, |
| location pointer variables are added for all the other templates. For every |
| CIF automaton <code>some.aut</code>, a location pointer variable <code>LP_some_aut</code> is |
| added. The location pointers are integer variables with range <code>[0,n-1]</code>, for |
| an automaton with <code>n</code> locations. Updates are added to the edges to ensure the |
| location pointer variables have the proper values. The location pointers are |
| similar to those created by the CIF to CIF transformation that |
| <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">eliminates the use of locations in expressions</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In CIF, assignments interpret the right hand side of the assignment (the new |
| value of the variable) in the source state of the transition. In UPPAAL, |
| assignments have order, and the right hand sides are interpreted over the |
| current state, after any preceding assignments. Furthermore, the order in which |
| the assignments of the edges of different participating templates are executed |
| is not defined. To ensure the proper CIF semantics, 'old' versions of all |
| variables (including the location pointer variables) are added. For a variable |
| <code>x</code>, <code>OLD_x</code> is added. The <code>SendAut</code> automaton assigns the current values |
| of all variables to their 'old' counterparts. The assignments on the edges of |
| the other automata then use the 'old' variables to compute the new values of |
| the variables. As the values of the 'old' variables are only used during the |
| transitions, the 'old' variables are <em>meta</em> variables in the UPPAAL system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The invariants from CIF components are added to the location of the <code>SendAut</code> |
| template.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For CIF variables with an <code>int</code> type, the UPPAAL type is |
| <code>int[-2147483648,2147483647]</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The names of templates, variables, etc in UPPAAL are based on the absolute |
| names of their CIF counterparts. For a variable <code>a.b.c</code> in CIF, the UPPAAL |
| name is <code>a_b_c</code>. If there are conflicts between the UPPAAL names, or if one |
| of the UPPAAL names conflicts with a UPPAAL keyword, renaming is performed, and |
| a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>No geometry is generated. When the generated UPPAAL file is opened in UPPAAL, |
| UPPAAL will perform some layouting.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-real-time-testing-code-generation-and-implementation-tools">Real-time testing, code generation, and implementation tools</h3> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-codegen-chapter-index">CIF code generator</h4> |
| <div class="paragraph"> |
| <p>The CIF code generator can be used to generate implementation code for |
| various languages/platforms. The generated code is complete, and can be used as |
| is, without any CIF related library or runtime.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The remainder of this page explains general information about the tool, that |
| applies to all target languages/platforms. Specific information is available |
| for each of the target languages/platforms, on separate pages:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-codegen-chapter-c89">C89</a> (if there is no <code>C99</code> compiler)</p> |
| </li> |
| <li> |
| <p><a href="#tools-codegen-chapter-c99">C99</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-codegen-chapter-java">Java</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-codegen-chapter-simulink">Simulink</a>, with an example of |
| <a href="#tools-codegen-chapter-simulink-example">controlling a tank</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-generator">Starting the generator</h5> |
| <div class="paragraph"> |
| <p>The generator can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the <b class="menuref">Project Explorer</b> |
| or <b class="menuref">Package Explorer</b> and choose |
| <span class="menuseq"><b class="menu">CIF implementation tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Generate code for CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF implementation tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Generate code for CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifcodegen</code> tool in a ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifcodegen</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options that apply to all target languages/platforms:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output directory</em>: The absolute or relative local file system path to the |
| output directory. This is the directory to which the generated code files |
| will be written. If the directory does not yet exist, it is automatically |
| created. By default, the current directory is used.</p> |
| </li> |
| <li> |
| <p><em>Target language</em>: Specifies the target language/platform for which to |
| generate code. By default, C99 code is generated. The following |
| languages/platforms are supported:</p> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Target language/platform</th> |
| <th class="tableblock halign-left valign-top">Command line value</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-codegen-chapter-c89">C89</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>c89</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-codegen-chapter-c99">C99</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>c99</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-codegen-chapter-java">Java</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-codegen-chapter-simulink">Simulink</a></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>simulink</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>The first column indicates the target language/platform, and is linked to a |
| page with more information for that specific language/platform. The second |
| column indicates the command line value to use for the option, to select that |
| target language/platform.</p> |
| </div> |
| </li> |
| <li> |
| <p><em>Code prefix</em>: The code prefix, used to prefix file names, identifiers in |
| the code, etc. If no prefix is given, the prefix is derived from the input |
| filename, by removing the <code>.cif</code> file extension, if present. This is also |
| the default. The prefix must be a valid CIF identifier, i.e. consist of only |
| letters (<code>a</code> to <code>z</code>, <code>A</code> to <code>Z</code>), numbers (<code>0</code> to <code>9</code>), and |
| underscores (<code>_</code>), and not start with a number.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-supported">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The CIF code generator supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Specifications without automata are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in components are not supported, except if it |
| can be determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>State invariants in components are not supported, except if it can be |
| determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>State/event exclusion invariants (in components as well as locations) are not |
| supported. To allow state/event exclusion invariants to be used in the input, |
| manually eliminate them first using the |
| <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">CIF to CIF transformation</a>.</p> |
| </li> |
| <li> |
| <p>Discrete variables with multiple initial values (including <code>any</code>) are not |
| supported.</p> |
| </li> |
| <li> |
| <p>External user-defined functions are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent locations are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in locations that can not be statically evaluated |
| are not supported.</p> |
| </li> |
| <li> |
| <p>State invariants in locations are not supported, except if it can be |
| determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>Automata that do not have exactly one initial location are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent edges are not supported.</p> |
| </li> |
| <li> |
| <p>Data types other than <code>bool</code>, <code>int</code> (with or without range), <code>real</code>, |
| <code>string</code>, enumerations, tuples, and arrays, are not supported. This applies |
| to the data types of variables, parameters of functions, return types of |
| functions, etc.</p> |
| </li> |
| <li> |
| <p>Sampling of distributions is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the conjunction and disjunction binary operators on anything other |
| than boolean values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the equality and inequality binary operators on anything other |
| than boolean, integer, real, string, or enumeration values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the addition binary operators on anything other than numeric or |
| string values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the subtraction binary operators on anything other than numeric |
| values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the element test and subset binary operators is not supported.</p> |
| </li> |
| <li> |
| <p>Projection on anything other than tuples, arrays, and strings is not |
| supported. This applies to expressions as well as addressables (the left hand |
| sides of assignments). For arrays, both 0-based indices (counting from the |
| left) as well as negative indices (counting from the right) are supported.</p> |
| </li> |
| <li> |
| <p>Slicing is not supported.</p> |
| </li> |
| <li> |
| <p>Function calls on anything other than standard library functions and internal |
| user-defined functions is not supported.</p> |
| </li> |
| <li> |
| <p>The <code>del</code>, <code>pop</code>, <code>acosh</code>, <code>asinh</code>, <code>atanh</code>, <code>cosh</code>, <code>sinh</code>, |
| and <code>tanh</code> standard library functions are not supported.</p> |
| </li> |
| <li> |
| <p>The <code>empty</code> standard library function on anything other than arrays is not |
| supported.</p> |
| </li> |
| <li> |
| <p>The <code>size</code> standard library function on anything other than strings and |
| arrays is not supported.</p> |
| </li> |
| <li> |
| <p>The distribution standard library functions are not supported.</p> |
| </li> |
| <li> |
| <p>Lists (except for arrays), sets, and dictionaries are not supported.</p> |
| </li> |
| <li> |
| <p>The use of functions as values is not supported. That is, functions may only |
| be used in function calls, and may for instance not be stored in variables, |
| or passed to other functions.</p> |
| </li> |
| <li> |
| <p>Print declarations with pre/source state text and post/target state filtering |
| (<code>when</code>) are not supported.</p> |
| </li> |
| <li> |
| <p>Print declarations with post/target state text and pre/source state filtering |
| (<code>when</code>) are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-6">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-cif-svg-decls">Remove CIF/SVG declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-others">Simplify others</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>After these preprocessing steps, the generator checks whether the specification |
| is supported. It then applies the following additional |
| <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-linearize-merge">Linearize (merge)</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-generated-code">Generated code</h5> |
| <div class="paragraph"> |
| <p>This section explains the basics behind the generated code, as they apply to |
| all target languages. The specific pages that explain the code generated for |
| specific target languages provide further details.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-code-overview">Code overview</h6> |
| <div class="paragraph"> |
| <p>The code that executes the edges of the CIF model is called the <em>event loop</em> |
| code. The event loop is not the only code that is executed. Before the loop, |
| the values of the input variables are obtained from the environment, the |
| initial state is initialized (for the first execution only), and the values of |
| the continuous variables are updated to account for the amount of time that has |
| passed (for all but the first execution). Then the event loop is executed. |
| Finally, output values may be supplied to the environment.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-repeated-execution">Repeated execution</h6> |
| <div class="paragraph"> |
| <p>During the execution of the code, variable <code>time</code> from the CIF model is |
| not updated. Execution of the code takes time. After the code is executed, |
| potentially more time passes. Then, the code can be executed again. The time |
| (in seconds) between the first execution and the current execution is the |
| total time that has passed since execution started, and this becomes the new |
| value of variable <code>time</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>How often the code is executed, and whether this is done with a fixed cycle |
| time (periodic task scheduling) or with a variable cycle times (non-periodic |
| tasks) can be influenced by the end user. The details differ per target |
| language, and can be found on their respective pages.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-event-loop">Event loop</h6> |
| <div class="paragraph"> |
| <p>The CIF model is first <a href="#tools-cif2cif-chapter-linearize-merge">linearized</a> to |
| eliminate parallel composition. The result is self loop edges with guards and |
| updates. The main part of the generated code essentially consists of update |
| code that is conditionally executed. This code executes edges. This is done |
| repeatedly, until no more events are enabled. The loop in the generated code |
| that repeatedly executes event code until no more events are possible, is |
| called the <em>event loop</em>. Once no more events are enabled, the event loop |
| terminates.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-event-order">Event order</h6> |
| <div class="paragraph"> |
| <p>The order in which the code is generated for the different edges (in the |
| <em>event loop</em>), is done in such a way that it matches the order in which |
| transitions are chosen by the simulator. Assuming the simulator is used to |
| simulate by always automatically choosing the |
| <a href="#tools-cifsim-input-chapter-automatic">first transition</a> that is enabled, the |
| generated code will choose that same transition. That is, for each iteration of |
| the event loop, the code is executed for the first event with an enabled guard. |
| Then, a new iteration of the loop is started, from the top, to ensure that the |
| first enabled event is always executed, similar to simulation. If during an |
| iteration of the loop none of the events is enabled, the event loop terminates.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-termination-2">Termination</h6> |
| <div class="paragraph"> |
| <p>If in the CIF model always at least one event is enabled, the generated code |
| will run forever, and will never terminate. Time will not pass. Code generation |
| should be avoided for such models. It is the responsibility of the modeler to |
| ensure this is taken into account.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-predictability-of-execution-time">Predictability of execution time</h6> |
| <div class="paragraph"> |
| <p>If at least one event is enabled, the event loop is executed again. If during |
| an iteration of the loop none of the edges is enabled, the loop terminates. |
| This approach generally does not result in predictable execution times of the |
| program body. That is, if a certain edge keeps being enabled, the loop is |
| executed over an over again. In that case, the execution time of the body |
| may exceed the fixed cycle time, and the controller is no longer guaranteed to |
| work correctly. Even if the loop is only executed a finite number of times, |
| the execution time of the body may exceed the fixed cycle time. One may |
| consider monitoring the execution times to detect such issues. All |
| implementations provide a way to obtain execution time statistics. The details |
| differ per target language, and can be found on their respective pages.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optional-execution-feedback">Optional execution feedback</h6> |
| <div class="paragraph"> |
| <p>Several implementations provide additional information during simulation, such as |
| which events have been executed, timing information, and what new print output |
| has been generated. Such information can generally be enabled and disabled in |
| the implementations. The details differ per target language, and can be found |
| on their respective pages.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-correct-handling-of-io">Correct handling of I/O</h6> |
| <div class="paragraph"> |
| <p>The generated code cannot guarantee its correct behavior if the inputs from the |
| external I/O change more rapidly than the generated code is executed. That is, |
| if an input changes during a single execution of the code, the change is not |
| noticed until the next execution. If an input changes during an execution and |
| changes back during that same execution, the change is not noticed at all. |
| Therefore, executing the code often enough per second, is essential. In other |
| words, choosing an appropriate cycle time is essential for the correct |
| functioning of the generated code.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-codegen-accuracy-over-time">Accuracy over time</h6> |
| <div class="paragraph"> |
| <p>The generated C89, C99 and Java code maintains the running time in seconds. |
| Due to the finite |
| representation of numeric values, this results in numeric overflow after |
| execution for a long time. Running the code continuously for longer than 100 |
| years should be avoided.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The continuous variables from the CIF specification in the generated code |
| are updated each execution |
| using the <a href="http://en.wikipedia.org/wiki/Euler_method">Euler method</a> for |
| integration. That is, each execution the time that has elapsed since the |
| previous execution is multiplied by the derivative of the continuous variable |
| in the state of the previous execution. This value is added to the value of the |
| continuous variable. Essentially, a linear approximation of the derivative is |
| used, calculated using the state of the previous execution.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The Euler method can be |
| <a href="http://en.wikipedia.org/wiki/Numerical_stability">numerically unstable</a>, it |
| can suffer from rounding |
| errors due to the use finite binary representations of real values, and has |
| some other issues as well. The effects are likely to be limited if linear |
| continuous variable (continuous variables with constant derivatives) are used. |
| Especially clocks (derivative +1 or -1) generally don’t suffer too much from |
| these issues. However, even clocks may suffer from loss of accuracy over time. |
| As such, clocks should not be used to measure over long periods of time. |
| Instead they should be reset, rendering the past loss of accuracy irrelevant |
| for any future measurements.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-enumerations">Enumerations</h6> |
| <div class="paragraph"> |
| <p>The <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a> that is used as |
| preprocessing, also <a href="#tools-cif2cif-chapter-merge-enums">merges all enumerations</a> |
| into a single enumeration. This is done in such a way that the behavior of the |
| original CIF model is left intact. However, it is up to the implementer that |
| connects the inputs from the environment to the generated code, to ensure that |
| only valid enumeration literals are assigned to the input variables of the |
| generated code.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-chapter-c89">C89 code generation</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The <a href="#tools-codegen-chapter-index">CIF code generator</a> can generate C89 code from a CIF |
| specification. It is assumed the reader of this page is familiar with the |
| general information of the CIF code generator tool. This page describes |
| specific information applicable only to C89 code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, use of the <a href="#tools-codegen-chapter-c99">C99</a> code generator is |
| preferred, as the language contains a decade longer development. However, in |
| the case there is no <code>c99</code> compiler available, the <code>c89</code> code generation |
| might be a useful fallback option to convert a CIF program for controlling a |
| real time system. The conversion uses a simple integrator |
| intended for updating running clocks (derivative should not change during |
| a time step for best results). Also, it does not compute length of the next |
| time step, but instead assumes being called regularly to update |
| internal state and perform discrete steps if possible.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-6">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>The CIF code generator supports a subset of CIF specifications. Generation |
| of C89 code does not impose additional restrictions. See the |
| <a href="#tools-codegen-supported">Supported specifications</a> section of the <a href="#tools-codegen-chapter-index">CIF code generator</a> |
| page for more information.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-differences-in-output">Differences in output</h6> |
| <div class="paragraph"> |
| <p>When converting a real number to text, for example when printing a real value, |
| the generated C89 code does not preserve trailing zeroes of real number |
| fractions while using <code>%g</code>. For example <code>fmt("%.3g", 1.0)</code> will output |
| <code>1</code> rather than <code>1.000</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This may cause real number values to be printed with less digits precision than |
| indicated in the CIF program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Strings have an upper limit in length that is set during compilation. Longer |
| strings are silently truncated to this length.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-15">Options</h6> |
| <div class="paragraph"> |
| <p>The C89 code generator only uses the <a href="#tools-codegen-options">common options</a> |
| that apply to all target languages/platforms of the |
| <a href="#tools-codegen-chapter-index">CIF code generator</a>, it has no options of its own.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The code prefix that can be configured using a common option is used to prefix |
| external names, making them unique for the generated code.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generated-files">Generated files</h6> |
| <div class="paragraph"> |
| <p>C89 code generation leads to creation of seven files:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 33.3333%;"> |
| <col style="width: 66.6667%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Generated file</th> |
| <th class="tableblock halign-left valign-top">Purpose</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_library.h</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Runtime support code and library headers</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_library.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Runtime support code and library implementation</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_engine.h</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Interface definition of the translated CIF program</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_engine.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Implementation of the translated CIF program</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_compile.sh</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Compile script for Linux</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_test_code.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Example of external functions, allow compiling the generated code</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_readme.txt</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Short description of use, the interface, and compile options</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>where <code><prefix></code> is replaced by the value of the <em>Code prefix</em> option during |
| code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The aim is to provide a complete and compilable package, to minimize the effort |
| in converting a CIF specification. Most files are static text (modulo |
| the <code><prefix></code> replacement). The two exceptions are both engine files that |
| contain the C89 version of the CIF specification. The interface of these files |
| is however fixed (modulo the <code><prefix></code> replacement), and generated data |
| types and operations on them have predictable names, reducing the chance of |
| failed compilation when re-generating the files.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When modifying a generated file (such as the compile script or the example test |
| code), keep in mind that running the code generator again will overwrite <em>all</em> |
| files. Rename a file before modifying it to avoid loss of work.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-compilation-of-the-generated-code">Compilation of the generated code</h6> |
| <div class="paragraph"> |
| <p>The generated code is C89 code that can be compiled using a C89 C compiler, like <code>gcc</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="shell">gcc -Wall -std=c89 -DPRINT_OUTPUT=1 -DCHECK_RANGES=1 \ |
| <prefix>_engine.c <prefix>_library.c <prefix>_test_code.c -lm</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The single <code>\</code> is not part of the command, it means the next line should be appended at the end.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code><prefix></code> should be replaced by the value of the <em>Code prefix</em> option during |
| code generation. The <code>PRINT_OUTPUT</code> and <code>CHECK_RANGES</code> macros enable |
| support for the CIF <code>print</code> statement and checking of integer range overlap, |
| as defined by CIF. In general however, you may want to replace the test code |
| file by your own code.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-c89-compile-time-options">C89 compile-time options</h6> |
| <div class="paragraph"> |
| <p>Besides the <code>PRINT_OUTPUT</code> and <code>CHECK_RANGES</code> macros, the generated code |
| has a few other compile-time options to customize its behavior. Below is the complete list.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 20%;"> |
| <col style="width: 80%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Macro name</th> |
| <th class="tableblock halign-left valign-top">Effect</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>MAX_STRING_SIZE</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">CIF has variable length strings, in the generated code they are converted to strings with a fixed |
| upper limit. Default is 128 (including the terminator character). Set this macro for a different limit. |
| <em>Note that both the library and the engine use this macro. It is crucial that both files use the same |
| value for this macro</em>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>CHECK_RANGES</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">When copying integers from one range to another, where the latter is only partially covered by the |
| former, CIF checks whether the copied values do not violate the destination range. Since violating |
| this property generally indicates a programming error, it is recommended to enable this macro.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>EVENT_OUTPUT</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">If set, the generated code calls <code><prefix>_InfoEvent()</code> before and after performing an event to |
| allow third-party code to act on it. Enable if your code needs to know when an event is performed.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>PRINT_OUTPUT</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">If set, the CIF <code>print</code> statement is performed, and the <code><prefix>__PrintOutput()</code> is called with |
| the resulting text and destination filename. Mainly intended for debugging, but only useful in |
| systems where the text can be displayed to a user.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>MAX_NUM_EVENTS</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The CIF semantics state that execution of edges is instantaneous and time-less. The generated code |
| loops to perform edges, until no edge can be executed any more. Unfortunately, such a loop is not |
| time-less. To avoid requiring too much time, there is an upper limit of 1000 iterations. Set this macro |
| to change the limit.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>KEEP_RUNNING</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The CIF language checks range conversions (if <code>CHECK_RANGES</code> is set) and verifies updates of |
| continuous variable updates. Setting this flag disables a few checks. Most of these checks are in |
| <code>assert()</code> checks and not controlled by this macro, since violating the condition generally means a |
| crash is eventually inevitable. It is recommended to avoid using this macro.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-executing-the-code">Executing the code</h6> |
| <div class="paragraph"> |
| <p>The engine files act as a library that implements the CIF program. To run the |
| program, the code must be called regularly. The code has two entry points, one |
| for initializing and performing the first steps, and one for handling a time |
| delay.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first entry point is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_EngineFirstStep(<span class="directive">void</span>)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This entry point initializes all the data, queries the values of the input |
| variables if present, and performs execution of edges until blocked on the |
| first time step or until hitting the <code>MAX_NUM_EVENTS</code> limit. Since this |
| resets the entire CIF program to its initial state, you should only call this |
| when the system being controlled is also (re-)initialized.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second entry point is more regularly called, after a period of time has passed:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_EngineTimeStep(<span class="predefined-type">double</span> delta)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By calling this entry point, you indicate that <code>delta</code> (> 0) time units have |
| passed. The code reads new values of the input variables, |
| <a href="#tools-codegen-accuracy-over-time">updates the continuous variables</a>, |
| and performs edges until all edges are blocked, or |
| hitting the <code>MAX_NUM_EVENTS</code> limit.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When the call of either entry point returns, you can query the value of the |
| variables to use as input for other parts of the system.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-environment-interface">Environment interface</h6> |
| <div class="paragraph"> |
| <p>Calling one of the above entry points causes the CIF program to be executed, |
| up to the next time step (assuming the <code>MAX_NUM_EVENTS</code> limit is high |
| enough). During the execution, the code performs a number of callbacks to get |
| information from the environment, to provide information about its actions, or |
| to deliver output. In addition, after each call, variables may be inspected by |
| the environment to get information about the decisions of the CIF program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The externally provided callback functions that are being used are:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_AssignInputVariables(<span class="directive">void</span>)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF program requests new values for all its input variables. In your |
| implementation of this function you should write values directly in the input |
| variables. Input variables are assumed to be independent of other parts of the |
| CIF program, in general you should not need other CIF program values to |
| implement this function.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If <code>EVENT_OUTPUT</code> is set during compilation, executed events are reported with:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_InfoEvent(<prefix>_Event_ event, BoolType pre)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If the <code>EVENT_OUTPUT</code> macro is set during compilation, the generated code |
| reports with this call that event event is about to (<code>pre</code> is <code>TRUE</code>), |
| or has been (<code>pre</code> is <code>FALSE</code>) executed. In the pre-event call, the event |
| can be executed, and all variables have their value before performing the |
| updates of the involved edges. In the post-event call, all variables have their |
| values updated as indicated in the updates of the edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Primary use of this call is to forward the decision to other parts of the |
| controlled system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Finally, if the <code>PRINT_OUTPUT</code> macro is set during compilation, the generated |
| code reports lines of output to be printed with the following function call:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_PrintOutput(<span class="directive">const</span> <span class="predefined-type">char</span> *line, <span class="directive">const</span> <span class="predefined-type">char</span> *fname)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It denotes that text <code>line</code> should be printed at file <code>fname</code>. The primary |
| uses of this call are to enable debugging the system, or to log relevant |
| events. Note that <code>fname</code> here can mean anything. It can mean a real file, |
| but also a pseudo-device like <code>:stdout</code> which is commonly used to print |
| output to the C <code>stdout</code> stream.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-data-access">Data access</h6> |
| <div class="paragraph"> |
| <p>Each CIF constant is available as a variable that does not change after |
| initialization. Each algebraic variable can be queried by calling a function |
| with the same name as the variable. The value of continuous variables is |
| available by accessing the equivalent variable in the generated code. The |
| derivative of each continuous variable is available as function named by the |
| variable, and the suffix <code>deriv</code>. The model time is available as |
| <code>model_time</code>. There is no derivative function of time. Internal functions are |
| available as well if required.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The engine header file lists the translated names. It should be easy to find |
| the relevant entry, as the generated code also documents the original name.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-data-types">Data types</h6> |
| <div class="paragraph"> |
| <p>The following table defines how CIF data types are converted in the C89 generated code.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF data type</th> |
| <th class="tableblock halign-left valign-top">C89 data type</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>BoolType</code> which is a typedef to <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>IntType</code> which is a typedef to <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>enum e = ...</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>Enum</code> which is a typedef to <code>enum Enum<prefix>_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>RealType</code> which is a typedef to <code>double</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>string</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>StringType</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list[n] t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>...Type</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(...)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>...Type</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>A few notes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The <code>...</code> in the C89 <code>...Type</code> name for arrays (fixed length lists) and |
| tuples is the <a href="#tools-codegen-c89-systematic-type-names">systematic type name</a> |
| of the array or tuple type.</p> |
| </li> |
| <li> |
| <p>Due to <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a> all enumerations |
| are merged into one. The generated C89 code always has exactly one translated |
| <code>enum</code>.</p> |
| </li> |
| <li> |
| <p>The elementary data types (<code>BoolType</code>, <code>IntType</code>, <code>RealType</code>, and |
| <code>StringType</code>) are defined in the library header file.</p> |
| </li> |
| <li> |
| <p>The <code>StringType</code> structure wraps a <code>char data[MAX_STRING_SIZE]</code> array. |
| The <code>struct</code> allows copying arrays by value using an assignment statement.</p> |
| </li> |
| <li> |
| <p>The array type (list with a fixed length) structure wraps a |
| <code><element-type> data[<size>]</code> array for the same reason. Copying an array |
| by assignment is allowed.</p> |
| </li> |
| <li> |
| <p>The tuple type is a structure with fields <code>_field0</code>, <code>_field1</code>, and so |
| on, where the type of each field in the structure matches with the type of |
| the CIF tuple field.</p> |
| </li> |
| <li> |
| <p>Boolean constants <code>true</code> and <code>false</code> are named <code>TRUE</code> and <code>FALSE</code> |
| respectively.</p> |
| </li> |
| <li> |
| <p>The <code>-0.0</code> value of doubles gets replaced by <code>0.0</code> to void subtle equality |
| problems.</p> |
| </li> |
| <li> |
| <p>Strings get silently truncated to <code>MAX_STRING_SIZE - 1</code> characters. They |
| are always terminated with a NUL character.</p> |
| </li> |
| <li> |
| <p>Enumeration values get <code>_<prefix>_</code> added in front to make them unique.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-codegen-c89-systematic-type-names">Systematic type names</h6> |
| <div class="paragraph"> |
| <p>For tuple and list types, the type is converted to a name in a systematic way, |
| making each type unique and predictable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The conversion composes a name of a type from the type of its elements, and |
| concatenates the result. The following conversion table applies:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 25%;"> |
| <col style="width: 75%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF type</th> |
| <th class="tableblock halign-left valign-top">Systematic name</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>B</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>I</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>enum e = ...</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>E</code> (Due to linearization, all enumerations are merged together to a |
| single enumeration. As such, always exactly one <code>enum</code> is generated for a |
| CIF model.)</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>R</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list[n] t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>A<n><t></code>, with <code><n></code> the length of the array, and <code><t></code> the systematic |
| type name of the element type of the array.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(t1, t2, t3, ..., tn)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>T<n><t1><t2><t3>...<tn></code>, with <code><n></code> the number of fields in the tuple, and |
| <code><t1></code> to <code><tn></code> the systematic type names of the fields.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>For example, type <code>list[5] int</code> is converted to <code>A5I</code>, and type |
| <code>tuple(list[5] int x; tuple(real a, b) z)</code> is converted to <code>T2A5IT2RR</code> |
| (concatenation of <code>T2</code> with the field type names <code>A5I</code> and <code>T2RR</code>).</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-runtime-errors">Runtime errors</h6> |
| <div class="paragraph"> |
| <p>The CIF language defines strict sets of allowed values for all data types, and |
| performs checking of these values at run time. The generated C89 code follows |
| that idea, and checks whether operations on data are safe. Most of these |
| checks are performed with an <code>assert</code>. Executed C code does not provide useful |
| stack traces by default, and original line numbers of e.g. a CIF program have no |
| meaning due to the linearization that is performed before code is generated. In |
| addition, the generated code is quite readable and it is not too hard to |
| understand what the code is doing at some C source line.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-chapter-c99">C99 code generation</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The <a href="#tools-codegen-chapter-index">CIF code generator</a> can generate C99 code from a CIF |
| specification. It is assumed the reader of this page is familiar with the |
| general information of the CIF code generator tool. This page describes |
| specific information applicable only to C99 code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The aim of the C99 code generation tool is to provide an easy conversion from |
| a CIF program to control of a real time system. It uses a simple integrator |
| intended for updating running clocks (derivative should not change during |
| a time step for best results). Also, it does not compute length of the next |
| time step, but instead assumes being called regularly to update |
| internal state and perform discrete steps if possible.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-7">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>The CIF code generator supports a subset of CIF specifications. Generation |
| of C99 code does not impose additional restrictions. See the |
| <a href="#tools-codegen-supported">Supported specifications</a> section of the <a href="#tools-codegen-chapter-index">CIF code generator</a> |
| page for more information.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-differences-in-output-2">Differences in output</h6> |
| <div class="paragraph"> |
| <p>When converting a real number to text, for example when printing a real value, |
| the generated C99 code does not preserve trailing zeroes of real number |
| fractions while using <code>%g</code>. For example <code>fmt("%.3g", 1.0)</code> will output |
| <code>1</code> rather than <code>1.000</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This may cause real number values to be printed with less digits precision than |
| indicated in the CIF program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Strings have an upper limit in length that is set during compilation. Longer |
| strings are silently truncated to this length.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-16">Options</h6> |
| <div class="paragraph"> |
| <p>The C99 code generator only uses the <a href="#tools-codegen-options">common options</a> that apply to all target languages/platforms of the |
| <a href="#tools-codegen-chapter-index">CIF code generator</a>, it has no options of its own.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The code prefix that can be configured using a common option is used to prefix |
| external names, making them unique for the generated code.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generated-files-2">Generated files</h6> |
| <div class="paragraph"> |
| <p>C99 code generation leads to creation of seven files:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 33.3333%;"> |
| <col style="width: 66.6667%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Generated file</th> |
| <th class="tableblock halign-left valign-top">Purpose</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_library.h</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Runtime support code and library headers</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_library.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Runtime support code and library implementation</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_engine.h</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Interface definition of the translated CIF program</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_engine.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Implementation of the translated CIF program</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_compile.sh</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Compile script for Linux</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_test_code.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Example of external functions, allow compiling the generated code</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>_readme.txt</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Short description of use, the interface, and compile options</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>where <code><prefix></code> is replaced by the value of the <em>Code prefix</em> option during |
| code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The aim is to provide a complete and compilable package, to minimize the effort |
| in converting a CIF specification. Most files are static text (modulo |
| the <code><prefix></code> replacement). The two exceptions are both engine files that |
| contain the C99 version of the CIF specification. The interface of these files |
| is however fixed (modulo the <code><prefix></code> replacement), and generated data |
| types and operations on them have predictable names, reducing the chance of |
| failed compilation when re-generating the files.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When modifying a generated file (such as the compile script or the example test |
| code), keep in mind that running the code generator again will overwrite <em>all</em> |
| files. Rename a file before modifying it to avoid loss of work.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-compilation-of-the-generated-code-2">Compilation of the generated code</h6> |
| <div class="paragraph"> |
| <p>The generated code is C99 code that can be compiled using a C99 C compiler, like <code>gcc</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="shell">gcc -Wall -std=c99 -DPRINT_OUTPUT=1 -DCHECK_RANGES=1 \ |
| <prefix>_engine.c <prefix>_library.c <prefix>_test_code.c -lm</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The single <code>\</code> is not part of the command, it means the next line should be appended at the end.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code><prefix></code> should be replaced by the value of the <em>Code prefix</em> option during |
| code generation. The <code>PRINT_OUTPUT</code> and <code>CHECK_RANGES</code> macros enable |
| support for the CIF <code>print</code> statement and checking of integer range overlap, |
| as defined by CIF. In general however, you may want to replace the test code |
| file by your own code.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-c99-compile-time-options">C99 compile-time options</h6> |
| <div class="paragraph"> |
| <p>Besides the <code>PRINT_OUTPUT</code> and <code>CHECK_RANGES</code> macros, the generated code |
| has a few other compile-time options to customize its behavior. Below is the complete list.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 20%;"> |
| <col style="width: 80%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Macro name</th> |
| <th class="tableblock halign-left valign-top">Effect</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>MAX_STRING_SIZE</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">CIF has variable length strings, in the generated code they are converted to strings with a fixed |
| upper limit. Default is 128 (including the terminator character). Set this macro for a different limit. |
| <em>Note that both the library and the engine use this macro. It is crucial that both files use the same |
| value for this macro</em>.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>CHECK_RANGES</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">When copying integers from one range to another, where the latter is only partially covered by the |
| former, CIF checks whether the copied values do not violate the destination range. Since violating |
| this property generally indicates a programming error, it is recommended to enable this macro.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>EVENT_OUTPUT</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">If set, the generated code calls <code><prefix>_InfoEvent()</code> before and after performing an event to |
| allow third-party code to act on it. Enable if your code needs to know when an event is performed.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>PRINT_OUTPUT</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">If set, the CIF <code>print</code> statement is performed, and the <code><prefix>__PrintOutput()</code> is called with |
| the resulting text and destination filename. Mainly intended for debugging, but only useful in |
| systems where the text can be displayed to a user.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>MAX_NUM_EVENTS</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The CIF semantics state that execution of edges is instantaneous and time-less. The generated code |
| loops to perform edges, until no edge can be executed any more. Unfortunately, such a loop is not |
| time-less. To avoid requiring too much time, there is an upper limit of 1000 iterations. Set this macro |
| to change the limit.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>KEEP_RUNNING</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The CIF language checks range conversions (if <code>CHECK_RANGES</code> is set) and verifies updates of |
| continuous variable updates. Setting this flag disables a few checks. Most of these checks are in |
| <code>assert()</code> checks and not controlled by this macro, since violating the condition generally means a |
| crash is eventually inevitable. It is recommended to avoid using this macro.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-executing-the-code-2">Executing the code</h6> |
| <div class="paragraph"> |
| <p>The engine files act as a library that implements the CIF program. To run the |
| program, the code must be called regularly. The code has two entry points, one |
| for initializing and performing the first steps, and one for handling a time |
| delay.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first entry point is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_EngineFirstStep(<span class="directive">void</span>)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This entry point initializes all the data, queries the values of the input |
| variables if present, and performs execution of edges until blocked on the |
| first time step or until hitting the <code>MAX_NUM_EVENTS</code> limit. Since this |
| resets the entire CIF program to its initial state, you should only call this |
| when the system being controlled is also (re-)initialized.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The second entry point is more regularly called, after a period of time has passed:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_EngineTimeStep(<span class="predefined-type">double</span> delta)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By calling this entry point, you indicate that <code>delta</code> (> 0) time units have |
| passed. The code reads new values of the input variables, |
| <a href="#tools-codegen-accuracy-over-time">updates the continuous variables</a>, |
| and performs edges until all edges are blocked, or |
| hitting the <code>MAX_NUM_EVENTS</code> limit.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When the call of either entry point returns, you can query the value of the |
| variables to use as input for other parts of the system.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-environment-interface-2">Environment interface</h6> |
| <div class="paragraph"> |
| <p>Calling one of the above entry points causes the CIF program to be executed, |
| up to the next time step (assuming the <code>MAX_NUM_EVENTS</code> limit is high |
| enough). During the execution, the code performs a number of callbacks to get |
| information from the environment, to provide information about its actions, or |
| to deliver output. In addition, after each call, variables may be inspected by |
| the environment to get information about the decisions of the CIF program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The externally provided callback functions that are being used are:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_AssignInputVariables(<span class="directive">void</span>)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF program requests new values for all its input variables. In your |
| implementation of this function you should write values directly in the input |
| variables. Input variables are assumed to be independent of other parts of the |
| CIF program, in general you should not need other CIF program values to |
| implement this function.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If <code>EVENT_OUTPUT</code> is set during compilation, executed events are reported with:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_InfoEvent(<prefix>_Event_ event, BoolType pre)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If the <code>EVENT_OUTPUT</code> macro is set during compilation, the generated code |
| reports with this call that event event is about to (<code>pre</code> is <code>TRUE</code>), |
| or has been (<code>pre</code> is <code>FALSE</code>) executed. In the pre-event call, the event |
| can be executed, and all variables have their value before performing the |
| updates of the involved edges. In the post-event call, all variables have their |
| values updated as indicated in the updates of the edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Primary use of this call is to forward the decision to other parts of the |
| controlled system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Finally, if the <code>PRINT_OUTPUT</code> macro is set during compilation, the generated |
| code reports lines of output to be printed with the following function call:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="c"><prefix>_PrintOutput(<span class="directive">const</span> <span class="predefined-type">char</span> *line, <span class="directive">const</span> <span class="predefined-type">char</span> *fname)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It denotes that text <code>line</code> should be printed at file <code>fname</code>. The primary |
| uses of this call are to enable debugging the system, or to log relevant |
| events. Note that <code>fname</code> here can mean anything. It can mean a real file, |
| but also a pseudo-device like <code>:stdout</code> which is commonly used to print |
| output to the C <code>stdout</code> stream.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-data-access-2">Data access</h6> |
| <div class="paragraph"> |
| <p>Each CIF constant is available as a variable that does not change after |
| initialization. Each algebraic variable can be queried by calling a function |
| with the same name as the variable. The value of continuous variables is |
| available by accessing the equivalent variable in the generated code. The |
| derivative of each continuous variable is available as function named by the |
| variable, and the suffix <code>deriv</code>. The model time is available as |
| <code>model_time</code>. There is no derivative function of time. Internal functions are |
| available as well if required.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The engine header file lists the translated names. It should be easy to find |
| the relevant entry, as the generated code also documents the original name.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-data-types-2">Data types</h6> |
| <div class="paragraph"> |
| <p>The following table defines how CIF data types are converted in the C99 generated code.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF data type</th> |
| <th class="tableblock halign-left valign-top">C99 data type</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>BoolType</code> which is a typedef to <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>IntType</code> which is a typedef to <code>int</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>enum e = ...</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>Enum</code> which is a typedef to <code>enum Enum<prefix>_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>RealType</code> which is a typedef to <code>double</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>string</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>StringType</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list[n] t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>...Type</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(...)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>...Type</code> which is a typedef to a <code>struct</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>A few notes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>The <code>...</code> in the C99 <code>...Type</code> name for arrays (fixed length lists) and |
| tuples is the <a href="#tools-codegen-c99-systematic-type-names">systematic type name</a> |
| of the array or tuple type.</p> |
| </li> |
| <li> |
| <p>Due to <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a> all enumerations |
| are merged into one. The generated C99 code always has exactly one translated |
| <code>enum</code>.</p> |
| </li> |
| <li> |
| <p>The elementary data types (<code>BoolType</code>, <code>IntType</code>, <code>RealType</code>, and |
| <code>StringType</code>) are defined in the library header file.</p> |
| </li> |
| <li> |
| <p>The <code>StringType</code> structure wraps a <code>char data[MAX_STRING_SIZE]</code> array. |
| The <code>struct</code> allows copying arrays by value using an assignment statement.</p> |
| </li> |
| <li> |
| <p>The array type (list with a fixed length) structure wraps a |
| <code><element-type> data[<size>]</code> array for the same reason. Copying an array |
| by assignment is allowed.</p> |
| </li> |
| <li> |
| <p>The tuple type is a structure with fields <code>_field0</code>, <code>_field1</code>, and so |
| on, where the type of each field in the structure matches with the type of |
| the CIF tuple field.</p> |
| </li> |
| <li> |
| <p>Boolean constants <code>true</code> and <code>false</code> are named <code>TRUE</code> and <code>FALSE</code> |
| respectively.</p> |
| </li> |
| <li> |
| <p>The <code>-0.0</code> value of doubles gets replaced by <code>0.0</code> to void subtle equality |
| problems.</p> |
| </li> |
| <li> |
| <p>Strings get silently truncated to <code>MAX_STRING_SIZE - 1</code> characters. They |
| are always terminated with a NUL character.</p> |
| </li> |
| <li> |
| <p>Enumeration values get <code>_<prefix>_</code> added in front to make them unique.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-codegen-c99-systematic-type-names">Systematic type names</h6> |
| <div class="paragraph"> |
| <p>For tuple and list types, the type is converted to a name in a systematic way, |
| making each type unique and predictable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The conversion composes a name of a type from the type of its elements, and |
| concatenates the result. The following conversion table applies:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 25%;"> |
| <col style="width: 75%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF type</th> |
| <th class="tableblock halign-left valign-top">Systematic name</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>B</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>I</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>enum e = ...</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>E</code> (Due to linearization, all enumerations are merged together to a |
| single enumeration. As such, always exactly one <code>enum</code> is generated for a |
| CIF model.)</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>R</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list[n] t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>A<n><t></code>, with <code><n></code> the length of the array, and <code><t></code> the systematic |
| type name of the element type of the array.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(t1, t2, t3, ..., tn)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>T<n><t1><t2><t3>...<tn></code>, with <code><n></code> the number of fields in the tuple, and |
| <code><t1></code> to <code><tn></code> the systematic type names of the fields.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>For example, type <code>list[5] int</code> is converted to <code>A5I</code>, and type |
| <code>tuple(list[5] int x; tuple(real a, b) z)</code> is converted to <code>T2A5IT2RR</code> |
| (concatenation of <code>T2</code> with the field type names <code>A5I</code> and <code>T2RR</code>).</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-runtime-errors-2">Runtime errors</h6> |
| <div class="paragraph"> |
| <p>The CIF language defines strict sets of allowed values for all data types, and |
| performs checking of these values at run time. The generated C99 code follows |
| that idea, and checks whether operations on data are safe. Most of these |
| checks are performed with an <code>assert</code>. Executed C code does not provide useful |
| stack traces by default, and original line numbers of e.g. a CIF program have no |
| meaning due to the linearization that is performed before code is generated. In |
| addition, the generated code is quite readable and it is not too hard to |
| understand what the code is doing at some C source line.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-chapter-java">Java code generation</h5> |
| <div class="paragraph"> |
| <p> |
| |
| The <a href="#tools-codegen-chapter-index">CIF code generator</a> can generate Java code from a CIF |
| specification. It is assumed the reader of this page is familiar with the |
| general information of the CIF code generator tool. This page describes |
| specific information applicable only to Java code generation.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-8">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>The CIF code generator supports a subset of CIF specifications. Generation |
| of Java code does not impose additional restrictions. See the |
| <a href="#tools-codegen-supported">Supported specifications</a> section of the <a href="#tools-codegen-chapter-index">CIF code generator</a> |
| page for more information.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-17">Options</h6> |
| <div class="paragraph"> |
| <p>Besides the <a href="#tools-codegen-options">common options</a> that apply to all |
| target languages/platforms of the <a href="#tools-codegen-chapter-index">CIF code generator</a>, the Java code |
| generation can be influenced by the following additional options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Java package</em>: The Java package in which to generate Java code. If not |
| specified, the code prefix is used. The specified package should be a valid |
| Java package name, and must not be empty.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The code prefix that can be configured using a common option, is used in the |
| generated Java code as prefix for class names.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-compilation">Compilation</h6> |
| <div class="paragraph"> |
| <p>The generated Java code can be compiled with a Java 7 compiler or newer.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The generated code is complete, and can be used as is, without any CIF related |
| library or runtime. No additional dependencies or libraries are required. |
| Only the standard Java libraries, part of any Java installation, are needed.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generated-files-3">Generated files</h6> |
| <div class="paragraph"> |
| <p>Java code generation leads to two Java files being generated:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code><prefix>.java</code></p> |
| </li> |
| <li> |
| <p><code><prefix>Test.java</code></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>where <code><prefix></code> is replaced by the code prefix configured using the |
| <em>Code prefix</em> option.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The first file contains the code for all the features of the CIF model in an |
| abstract class named <code><prefix></code>. The second file contains a class named |
| <code><prefix>Test</code>, which inherits from the <code><prefix></code> class, and implements |
| various abstract methods. This test class can be used to test the code, and |
| can serve as a starting point for actually implementing the coupling between |
| the code generated for the CIF model, and the environment in which it runs.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-executing-the-code-3">Executing the code</h6> |
| <div class="paragraph"> |
| <p>The code can be executed in multiple ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>execOnce</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">void</span> execOnce(<span class="type">double</span> newTime)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Invoke this method to execute the code once. Inputs are read, transitions are |
| executed until none are possible, output is written, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>newTime</code> is the time in seconds, since the start of the first |
| execution of this method. For each invocation, the time that has elapsed |
| so far should be provided. This becomes the new value of variable <code>time</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Using this method, you decide when you invoke this method, and with what |
| values to use for variable <code>time</code>. This approach allows full control.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>exec</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">void</span> exec(<span class="type">long</span> frequency)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Invoke this method to execute the code repeatedly, without ever stopping. |
| This repeatedly invokes the <code>execOnce</code> method.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>frequency</code> can be used to configure how often, in number of times per |
| second, the code should be executed. By given a frequency of <code>100</code>, the |
| method attempts to execute the code every 10 milliseconds. If a single |
| execution takes less than 10 milliseconds, the method will sleep for the |
| remainder of what is left of the 10 milliseconds. However, if a single |
| execution takes more than 10 milliseconds, the next execution is immediately |
| started.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is also possible to execute the code repeatedly, as fast as possible, |
| without any delays. As soon as a single execution has finished, another |
| execution is started. This kind of behavior can be obtained by providing a |
| negative or zero value for <code>frequency</code>.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-environment-interface-3">Environment interface</h6> |
| <div class="paragraph"> |
| <p>The code generated for the CIF model does not do anything useful by itself. |
| Only once it is coupled to the environment, can the CIF model become useful. |
| The following methods are provided in the interface of the generated class as |
| abstract methods, and need to be implemented in a derived class:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><code>updateInputs</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> updateInputs()</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In this method, you should update the values of the input variables of the |
| CIF model. Note that you should obtain these from the environment. You should |
| not access the state of the CIF model from this method, as it may not be |
| initialized or up-to-date yet.</p> |
| </div> |
| <div class="paragraph"> |
| <p>An example of how to update the input variables, can be found in the |
| generated <code><prefix>Test</code> class. There, each input variable is assigned the |
| default value for its data type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If you want to update the variable, you should always assign completely new |
| fresh values. Don’t modify arrays and tuples in-place, as that may lead to |
| other variables being changed as well.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>preExec</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> preExec()</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This method is invoked each time, just before the code for the CIF model is |
| executed. This method is invoked before the <code>updateInputs</code> method is |
| invoked.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You should not access the state of the CIF model from this method, as it may |
| not be initialized or up-to-date yet.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>postExec</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> postExec()</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This method is invoked each time, just after the code for the CIF model is |
| executed. |
| In this method, you should write the output variables of the CIF model to |
| the environment. Since the code for the CIF model was just executed, these |
| variables may have new values.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All discrete and continuous variables of the CIF model are available, as are |
| variable <code>time</code> and the current locations of all of the automata of the |
| CIF model.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The code to write the output values to the environment is the dual to reading |
| the inputs from the environment, as is done in the <code>updateInputs</code> method.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>infoExec</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> infoExec(<span class="type">long</span> duration, <span class="type">long</span> cycleTime)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This method informs about the duration of a single execution of the code |
| generated for the CIF model. |
| The <code>duration</code> is the total number of nanoseconds spent executing the code. |
| The <code>cycleTime</code> is the desired maximum duration of the execution, in |
| nanoseconds, or <code>-1</code> if not available.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You can use this method to detect when the code runs longer than the desired |
| maximum duration, and thus the desired execution frequency can not be |
| achieved. You can also use this method to figure out the variability of the |
| duration of execution.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>doInfoExec</code> field of the class can be used to configure whether this |
| method is invoked during execution by the <code>exec</code> method. This is enabled |
| (<code>true</code>) by default.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>infoEvent</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> infoEvent(<span class="type">int</span> idx, <span class="type">boolean</span> pre)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This method informs about events that are about to be executed or have just |
| been executed. |
| The <code>idx</code> is the 0-based index of the event. You can feed this index to the |
| <code>getEventName</code> method to obtain the absolute name of the event. The <code>pre</code> |
| is <code>true</code> if the event is about to be executed, and <code>false</code> if the event |
| has just been executed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You can use this method to be informed about what the code does during |
| execution. You could for instance log that for debugging.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>doInfoEvent</code> field of the class can be used to configure whether this |
| method is invoked during execution. This is disabled (<code>false</code>) by default.</p> |
| </div> |
| </li> |
| <li> |
| <p><code>infoPrintOutput</code> method</p> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="java"><span class="directive">protected</span> <span class="type">void</span> infoPrintOutput(<span class="predefined-type">String</span> text, <span class="predefined-type">String</span> target)</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This method informs that new print output has been generated during |
| execution. |
| The <code>text</code> is the text that is to be printed. The <code>target</code> indicates the |
| file or special target to which text is to be printed. If printed to a file, |
| an absolute or relative local file system path is given. Paths may contain |
| both <code>/</code> and <code>\</code> as path separators. Supply the path to the |
| <code><prefix>Utils.normalizePrintTarget</code> method to normalize the path to use |
| path separators for the current platform on which the Java code is executed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are two special targets: <code>:stdout</code> to print to the standard output |
| stream, and <code>:stderr</code> to print to the standard error stream.</p> |
| </div> |
| <div class="paragraph"> |
| <p>You should use this method to actually print the text to standard output, |
| standard error, or files. An example of how to do this, can be found in the |
| generated <code><prefix>Test</code> class.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>doInfoPrintOutput</code> field of the class can be used to configure whether |
| this method is invoked during execution. This is enabled (<code>true</code>) by default.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-data-access-and-manipulation">Data access and manipulation</h6> |
| <div class="paragraph"> |
| <p>For each CIF constant, a field is generated in the Java class. Similar fields |
| are generated for the state variables (discrete and continuous variables), and |
| the input variables. A <code>time</code> field is always present and contains the |
| current model time.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For each internal user-defined function of the CIF model, a method is generated |
| in the Java class. Similarly, a method is generated for each algebraic variable |
| of the CIF model, as well as for the derivative of each continuous variable |
| (except variable <code>time</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The standard library functions and operators that are supported by the code |
| generation, are also available, in the <code><prefix>Utils</code> inner class. Not all |
| operators and standard library functions are available. Only those that have |
| no corresponding Java operator or method, or behave differently with respect to |
| runtime errors, are available in this inner class.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For more information on the names of the generated field and methods, see the |
| section on <a href="#tools-codegen-java-naming">naming</a> below.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-codegen-java-datatypes">Data types</h6> |
| <div class="paragraph"> |
| <p>The following table lists CIF types supported by the code generator, and their |
| equivalent in the generated Java code:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 20%;"> |
| <col style="width: 40%;"> |
| <col style="width: 40%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF type</th> |
| <th class="tableblock halign-left valign-top">Java type</th> |
| <th class="tableblock halign-left valign-top">Tuple postfix</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bool</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>boolean</code> / <code>java.lang.Boolean</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>B</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code> (with or without range)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>int</code> / <code>java.lang.Integer</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>I</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>real</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>double</code> / <code>java.lang.Double</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>R</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>string</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.lang.String</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>S</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>list[...] t</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>java.util.List<t></code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Lt</code>, with <code>t</code> a postfix for the element type</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>enum e = ...</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>Enum</code> inner enumeration (class)</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>E</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>tuple(...)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>CifTuple_T...</code> inner class</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>TnFFF</code>, with <code>n</code> the number of fields, and <code>FFF</code> a postfix for |
| the type of each field.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Notes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>For each unique tuple type (ignoring integer and array ranges |
| of the types of the fields, as well as field names) an inner |
| Java class is generated. Their names all start with |
| <code>CifTuple_</code>, and end in a postfix that describes the type. |
| The <em>Tuple postfix</em> column in the table lists the texts used for each |
| type in the postfix. For instance, for a |
| <code>tuple(tuple(int x; real y; string z) a, list[3] int b)</code> |
| type, the tuple class would be named <code>CifTuple_T2T3IRSLI</code>.</p> |
| </li> |
| <li> |
| <p>For <code>boolean</code>, <code>int</code>, and <code>double</code>, the primitive type is preferred. It’s boxed |
| variant is used when needed, for instance for element types of a |
| <code>java.util.List<...></code> class.</p> |
| </li> |
| <li> |
| <p>Generic lists are not supported, only CIF arrays can be used.</p> |
| </li> |
| <li> |
| <p>As linearization is applied on the CIF model prior to generating Java code, |
| all enumerations are merged together to a single enumeration. As such, always |
| exactly one Java <code>enum</code> is generated for a CIF model.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-runtime-errors-3">Runtime errors</h6> |
| <div class="paragraph"> |
| <p>Some CIF models that are syntactically valid, may lead to runtime errors when |
| simulated or executed. For instance, there may be a division by zero, an out |
| of bounds projection, or an assignment may lead to the range of the assigned |
| variable being violated. The generated Java code detects all such problems and |
| throws a <code><prefix>Exception</code> in such cases. This exception class is an inner |
| class of the <code><prefix></code> class. The exception indicates what caused the |
| runtime error, using an informative end-user readable message.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-codegen-java-naming">Naming</h6> |
| <div class="paragraph"> |
| <p>The generated code will contain names for variables, functions, etc. The names |
| in the generated code are based on the absolute names of the objects in the |
| original CIF model. The names are further influenced by the |
| <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a> algorithm. Essentially, |
| the absolute names are used, where each <code>.</code> is replaced by a <code>_</code>. |
| Furthermore, a <code>_</code> is added at the end, to avoid conflicts with other |
| non-generated names, Java keywords, etc. For instance, for an automaton <code>a</code> |
| with a discrete variable <code>b</code> in it, the absolute name is <code>a.b</code>. In the |
| Java code, the variable will be named <code>a_b_</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The code generator ensures unique names in the generated Java code. If the |
| same Java name results from two different CIF objects, one of them is renamed, |
| by adding a <code>2</code>, or <code>3</code>, or <code>4</code>, etc to make it unique. For instance, |
| if the CIF model has a constant named <code>a_b</code> in the top level scope, and a |
| constant named <code>b</code> in the <code>a</code> automaton, both would be named <code>a_b_</code>. One |
| of them is renamed to <code>a_b_2</code>. If such renaming takes place, a warning is |
| printed to the console.</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 40%;"> |
| <col style="width: 20%;"> |
| <col style="width: 20%;"> |
| <col style="width: 20%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">CIF model</th> |
| <th class="tableblock halign-left valign-top">Java code</th> |
| <th class="tableblock halign-left valign-top">Example CIF name</th> |
| <th class="tableblock halign-left valign-top">Example Java name</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Constant</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Field</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Discrete variable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Field</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Continuous variable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Field</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Derivative of a continuous variable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Method</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b'</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_deriv()</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Algebraic variable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Method</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_()</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Input variable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Field</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">User-defined function</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Method</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_()</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Parameter of a user-defined function</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Method parameter</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Local variable of an internal user-defined function</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Local variable of a method</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a_b_</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enumeration</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enumeration</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>Enum</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enumeration literal</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Enumeration constant</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>a.b.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>Enum._c</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Tuple type</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Inner class</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">n/a</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>CifTuple_T...</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Notes:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>As linearization is applied on the CIF model prior to generating Java code, |
| all enumerations are merged together to a single enumeration. As such, always |
| exactly one Java <code>enum</code> is generated for a CIF model.</p> |
| </li> |
| <li> |
| <p>For details on tuple types and the classes that are generated for them, |
| see the <a href="#tools-codegen-java-datatypes">data types</a> section above.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-chapter-simulink">Simulink C S-Function code generation</h5> |
| <div class="paragraph"> |
| <p>Everywhere at this page, the terms <em>Matlab</em>, <em>Simulink</em>, <em>S-Function</em>, and |
| <em>Mex</em> refer to products and programs developed and owned by <em>MathWorks</em>. For |
| more information, please visit <a href="http://mathworks.com/" class="bare">http://mathworks.com/</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <a href="#tools-codegen-chapter-index">CIF code generator</a> can generate Matlab Simulink S-Function C code |
| from a CIF specification. It is assumed the reader of this page is familiar with the |
| general information of the CIF code generator tool. This page describes |
| specific information applicable only to Simulink code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The aim of the the conversion from CIF to Simulink is to provide a smooth path |
| from a CIF specification to a controlled real-time system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At this page, all the details about the Simulink code generation are discussed. |
| For an example of how to use this code generation in practice, read |
| <a href="#tools-codegen-chapter-simulink-example">the example</a>.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-9">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>The CIF code generator supports a subset of CIF specifications. See the |
| <a href="#tools-codegen-supported">Supported specifications</a> section of the <a href="#tools-codegen-chapter-index">CIF code generator</a> page |
| for more information. Generation of Simulink S-Function C code adds |
| a restriction to the type of CIF input variables caused by limitations in |
| Simulink input ports.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Simulink input ports can only handle real and complex signals. The latter |
| cannot be expressed in CIF, while the former creates the need for CIF input |
| variables with data types that can be relatively easily converted to real |
| number values. For this reason, CIF input variables must have a boolean, |
| enumeration, integer, or real elementary type. Arrays (fixed length CIF lists) |
| of these elementary types are also supported, they are converted to a vector |
| of real numbers at a Simulink input port. Finally, arrays of arrays of the |
| elementary types are converted to a matrix of real numbers at a Simulink input |
| port.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Data types of all other CIF variables have no additional constraints. However, |
| Simulink poses similar restrictions to its other data vectors, in particular |
| the output ports. The CIF to Simulink code generator toool only makes |
| variables available for output that are compatible with real number, vectors |
| of real numbers, or matrices of real numbers. |
| That means that use of the CIF string type, the tuple type, or arrays with |
| a deeper nesting than two levels will not be available at the output.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-differences-in-output-3">Differences in output</h6> |
| <div class="paragraph"> |
| <p>When converting a real number to text, for example when printing a real value, |
| the generated Simulink code does not preserve trailing zeroes of real number |
| fractions while using <code>%g</code>. For example <code>fmt("%.3g", 1.0)</code> will output |
| <code>1</code> rather than <code>1.000</code>. |
| This may cause real number values to be printed with less digits precision than |
| indicated in the CIF program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Strings have an upper limit in length that is set during compilation. Longer |
| strings are silently truncated to this length.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF print statement is supported, but only for the <code>:stdout</code> file. It |
| is translated to the <code>ssPrintf</code> C function. This is also the only way to get |
| a string to appear outside the Simulink S-Function block. Note that Simulink |
| may drop the output function for platforms that have no output possibilities.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-options-18">Options</h6> |
| <div class="paragraph"> |
| <p>The CIF to Simulink code generator uses the <a href="#tools-codegen-options">common options</a> |
| that apply to all target languages/platforms of the |
| <a href="#tools-codegen-chapter-index">CIF code generator</a>. It also has the additional options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Simulink Outputs</em>: This option takes a list of CIF variables that should be |
| made available as output of the generated S-Function. Only location |
| varaiables (automata), discrete variables, continuous variables, and |
| algebraic variables can be selected. The option also allows to use the |
| wildcard character <code>*</code>, which represents zero or more characters from the |
| name. You can use it to match several variables at once, for example |
| <code>*out</code> matches all variables that end with <code>out</code>. The special name |
| <code>nothing</code> means that no output should be produced at all.</p> |
| </li> |
| <li> |
| <p><em>Simulink sample time</em>: This option controls how Simulink samples the |
| generated block. Allowed values are <code>continuous</code>, <code>inherited</code>, |
| <code>variable</code>, or a sample period. Check the Mathworks <code>ssSetSampleTime</code> |
| function documentation for details which to use. By default, sample time is |
| set to <code>continuous</code>.</p> |
| </li> |
| <li> |
| <p><em>Simulink sample offset</em>: This option controls the offset of sampling. Its |
| allowed values depend on the value of the <em>Simulink sample time</em> option. |
| Possible values are <code>fixed</code>, <code>0.0</code>, or a positive non-zero value. Check |
| the Mathworks <code>ssSetSampleOffset</code> function documentation for details which |
| to use. By default, this options is set to <code>0.0</code>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The code prefix that can be configured using a common option is used as name |
| for the generated S-Function.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generated-files-4">Generated files</h6> |
| <div class="paragraph"> |
| <p>Running the Simulink code generator produces two output files:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 25%;"> |
| <col style="width: 75%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Generated file</th> |
| <th class="tableblock halign-left valign-top">Contents</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code><prefix>.c</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">The generated Simulink S-Function C code.</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Report file</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">Links CIF variables to Simulink entries.</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>where <code><prefix></code> is replaced by the value of the <em>Code prefix</em> option during |
| code generation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <code><prefix>.c</code> file contains the source code of the actual S-Function. The |
| file can be compiled using the Matlab Mex C compiler. The resulting mex file |
| can be used in Simulink (Open the <b class="menuref">Simulink Library</b>, select |
| <b class="menuref">User-defined functions</b>, and then the <b class="menuref">S-Function</b> block, |
| drag it into the Simulink canvas, open the block , and type the <code><prefix></code> |
| name into the <b class="menuref">Name</b> field.)</p> |
| </div> |
| <div class="paragraph"> |
| <p>The report file lists how CIF variables got mapped onto |
| the input, mode, contstate, and output Simulink vectors. You can use this |
| information to connect your CIF program with the other parts of the Simulink model.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-codegen-chapter-simulink-example">Simulink code generation and simulation example</h5> |
| <div class="paragraph"> |
| <p>The <a href="#tools-codegen-chapter-simulink">Simulink C S-Function code generation</a> can generate Simulink C code from a |
| CIF specification. Here an example is given to demonstrate how the code |
| generator can be used to control a model in Simulink.</p> |
| </div> |
| <div class="paragraph"> |
| <p><em>Matlab</em> and <em>Simulink</em> are products owned by <a href="http://mathworks.com">Mathworks</a>.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-system-to-control">System to control</h6> |
| <div class="paragraph"> |
| <p>The system to control is a simple water tank, as shown below.</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/tank.svg" alt="tank"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The water in the tank has volume <code>V</code>. At the bottom of the tank is a pipe |
| where water flows away with speed <code>Qo</code>. At the top is a pipe with valve |
| <code>n</code> that can be open or closed. The <code>Qi</code> variable denotes the speed of |
| water flowing into the tank. The equations that hold in this system are:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">Qi = n * 5 |
| Qo = sqrt(V) |
| V' = Qi - Qo</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By switching <code>n</code> on or off, a controller can control the amount of water |
| flowing into the tank, and with that, control the volume <code>V</code>. The objective |
| is to keep the volume between 2 and 10.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-controller-in-cif">Controller in CIF</h6> |
| <div class="paragraph"> |
| <p>A switching controller will be sufficient to control this system. In CIF that |
| results in a <code>tank_ctrl.cif</code> file containing:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event open_valve; |
| |
| automaton controller: |
| disc int n = 0; |
| input real V; |
| |
| location closed: |
| initial; |
| edge open_valve when V <= 2 do n := 1 goto opened; |
| |
| location opened: |
| edge when V >= 10 do n := 0 goto closed; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The controller has the control variable <code>n</code>, and input variable <code>V</code>. When |
| the volume of the tank is below 2, <code>n</code> is set to <code>1</code>, which turns on the |
| inflow. When the volume of the tank is high enough, <code>n</code> is set to <code>0</code> |
| which turns the inflow off.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generating-simulink-c-code">Generating Simulink C code</h6> |
| <div class="paragraph"> |
| <p>To simulate the controlled system in Simulink, the code generator tool can |
| produce C code for Simulink that can be used in a Simulink <em>System SFunction</em> block. |
| Convert the CIF model to C for Simulink with the code generation tool, by |
| selecting the code generation tool from the menu under the right mouse button:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/rmb-generate-code.png" alt="rmb generate code"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>By default, you will get all internal variables at the output of the |
| SFunction, which is often too much. The <em>Simulink Generation</em> tab allows |
| precise definition of what output variables should be added, in this case all |
| variables in the <code>controller</code> automaton. (Input variables are never made |
| available from the CIF SFunction block, as they are already available in Simulink.)</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/set-output-variables.png" alt="set output variables"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>After selecting <em>OK</em>, the CIF model is translated to C code. Code generation |
| from the <code>tank_ctrl.cif</code> files results in two output files. The |
| <code>tank_ctrl.c</code> file contains the generated C source code. The |
| <code>tank_ctrl_report.txt</code> is a text file describing the data of the generated |
| SFunction code:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code>Input/output report of the tank_ctrl.cif SFunction. |
| |
| During code generation, CIF variables are made available in the Simulink vectors. |
| This report lists the variables in each vector, along with their index number. |
| |
| Modes |
| ----- |
| controller 1 |
| |
| Continuous states |
| ----------------- |
| time 1 |
| |
| Inputs |
| ------ |
| controller.V 1 |
| |
| Outputs |
| ------- |
| controller.n 1</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The report shows which CIF variables are available at each vector. The |
| <em>Inputs</em> and <em>Outputs</em> are the most interesting. Here it shows that <code>V</code> is |
| the only input variable, <code>n</code> is the only output variable, and they are both |
| the first value in their vector. This is what you would expect for such |
| a small system. With bigger systems, the index numbers are much more useful |
| for making proper connections in Simulink.</p> |
| </div> |
| <div class="paragraph"> |
| <p>And this concludes the CIF part of this example, next step is setting things |
| up in Matlab/Simulink.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-simulation-in-simulink">Simulation in Simulink</h6> |
| <div class="paragraph"> |
| <p>After starting <em>Matlab</em>, and moving to the correct directory, you get |
| a display like:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/matlab-mex.png" alt="matlab mex"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>You can see the files present in the directory, as you would expect. In |
| Matlab, the generated C code is compiled with the Matlab <em>Mex</em> |
| compiler:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="shell">mex tank_ctrl.c</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the compiler prints a warning about the wrong compiler version, this may |
| be different at your system.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The result of the compilation is a <code>tank_ctrl.mexa64</code> file at a 64 bit |
| system. If you use a 32 bit system, the filename extension is different.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The compiled CIF controller can be used in a Simulink <em>System SFunction</em> |
| block, as shown below.</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/simulink-controlled-system.png" alt="simulink controlled system"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the middle the equations are modeled. The output of the equations is <code>V</code>, |
| which is fed into the <code>S-Function</code> block with the CIF controller at the top. |
| The controller computes <code>n</code> which is an input for the equations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At the bottom, a scope is attached that produces the following picture.</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/codegen/simulink-example/simulation-graph.png" alt="simulation graph"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The volume fluctuates between 2 and 10, at the bottom is the control signal |
| <code>n</code>.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-cif2plc-chapter-index">CIF PLC code generator</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| The CIF PLC code generator can be used to generate <strong>P</strong>rogrammable |
| <strong>L</strong>ogic <strong>C</strong>ontroller (PLC) code, for the implementation of CIF |
| controllers on PLCs. The generated PLC code adheres to the IEC 61131-3 |
| standard, a widely used international standard for PLC programming languages.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-generator-2">Starting the generator</h5> |
| <div class="paragraph"> |
| <p>The generator can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF implementation tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Generate PLC code for CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF implementation tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Generate PLC code for CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2plc</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2plc</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output file. Depending on the <a href="#tools-cif2plc-output-type">output type</a>, |
| this is either a file or a directory. The default depends on the output type |
| as well.</p> |
| </li> |
| <li> |
| <p><em>PLC code output type</em>: The PLC code <a href="#tools-cif2plc-output-type">output type</a> |
| specifies the type of output (essentially the file format) that should be generated.</p> |
| </li> |
| <li> |
| <p><em>PLC task name</em>: The name of the PLC task to generate. If not specified, |
| defaults to <code>PlcTask</code>.</p> |
| </li> |
| <li> |
| <p><em>PLC task cycle time</em>: If periodic task scheduling is to be used, use this |
| option to enable it, by setting the cycle time in milliseconds for the task |
| to generate. The cycle time must be a positive integer number. Cycle times of |
| over a minute may not work as expected. However, since such large cycle times |
| are of little practical use, that should not be a problem. Disable this |
| option to disable periodic task scheduling. This option defaults to periodic |
| task scheduling with a cycle time of 10 milliseconds. Disabling periodic task |
| scheduling is not supported for the TwinCAT <a href="#tools-cif2plc-output-type">output type</a>.</p> |
| </li> |
| <li> |
| <p><em>PLC task priority</em>: The scheduling priority of the task to generate. The |
| priority must be in the range [0 .. 65535], where priority 0 is the highest |
| priority, and priority 65535 is the lowest priority. The priority can be used |
| for preemptive or non-preemptive scheduling. If not specified, the priority |
| defaults to 20.</p> |
| </li> |
| <li> |
| <p><em>PLC project name</em>: The name of the PLC project to generate. If not |
| specified, defaults to <code>Untitled1</code>.</p> |
| </li> |
| <li> |
| <p><em>PLC configuration name</em>: The name of the PLC configuration to generate. If |
| not specified, defaults to <code>Untitled1</code>.</p> |
| </li> |
| <li> |
| <p><em>PLC resource name</em>: The name of the PLC resource to generate. If not |
| specified, defaults to <code>Untitled1</code>.</p> |
| </li> |
| <li> |
| <p><em>PLC number bits</em>: The maximum number of bits supported by the PLC for |
| representing numeric values. Use 64-bit if supported by the PLC, for full CIF |
| compatibility, and the highest <a href="#tools-cif2plc-accuracy">accuracy</a>. If |
| the PLC does not supported 64-bit integer and floating point numbers, set |
| this option to 32-bit.</p> |
| </li> |
| <li> |
| <p><em>PLC maximum iterations</em>: The maximum number of iterations of the main loop |
| of the main program body, per execution of the main program body. Must be |
| a positive number. May be set to infinite, to not impose a restriction. The |
| default is set to at most 100 iterations. See the section on the |
| <a href="#tools-cif2plc-progbody">program body</a> for more information.</p> |
| </li> |
| <li> |
| <p><em>Formal function invocation (arguments based)</em>: Specifies for which functions |
| to use formal invocation syntax in the generated PLC code. By default the |
| formal syntax is used for none of the functions. For PLC implementations that |
| don’t support the non-formal syntax, the formal syntax can be used for all |
| functions, or only for functions with more than one argument.</p> |
| </li> |
| <li> |
| <p><em>Formal function invocation (function kind based)</em>: Specifies for which |
| functions to use formal invocation syntax in the generated PLC code. By |
| default the formal syntax is used only for all but the standard |
| library/conversion functions. This can be changed to only the standard |
| library/conversion functions, or to all functions.</p> |
| </li> |
| <li> |
| <p><em>Eliminate enumerations</em>: Enable this option to eliminate enumerations before |
| generating the actual PLC code, in case the PLC doesn’t support enumerations. |
| Disable this option to keep enumerations in the generated PLC code. By |
| default this option is disabled.</p> |
| </li> |
| <li> |
| <p><em>Simplify values</em>: Enable this option to simplify values and inline constants |
| during generation of the PLC code. The benefit is that static computations |
| are evaluated, and for the result simpler PLC code is generated. This applies |
| to both the original model as well as anything generated during the code |
| generation, for instance as the result of |
| <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a>. Enabling the option |
| may thus lead to simpler PLC code. However, the simplification itself may |
| take quite some time. Furthermore, as constants are inlined, they are |
| duplicated for each use. If a constant with a large value (such as a large |
| literal array) is used multiple times, this can lead to significantly larger |
| PLC code. By default this option is enabled.</p> |
| </li> |
| <li> |
| <p><em>Rename warnings</em>: Enable this option to print warnings to the console when |
| a PLC name is renamed due to a conflict with another PLC name, or disable it |
| to omit the warnings. The option is disabled by default. See the section on |
| <a href="#tools-cif2plc-names">names</a> for more information.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Formal function invocation syntax (e.g. <code>MIN(IN1:3, IN2:5)</code>) is used in the |
| generated PLC code only for those functions that are included by both the |
| <b class="menuref">Formal function invocation (arguments based)</b> |
| option and the |
| <b class="menuref">Formal function invocation (function kind based)</b> |
| option. If either |
| of the options excludes the function, the non-formal function invocation syntax |
| (e.g. <code>MIN(3, 5)</code>) is used for that function. Note that for invocations of |
| function blocks, the generated PLC code always uses the formal syntax. |
| Furthermore, for certain standard library functions, only the non-formal syntax |
| is defined by the standard, and thus used in the generated PLC code.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-10">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The CIF PLC code generator supports a subset of CIF specifications. The |
| following restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Unrestricted events are not supported, as they can always be executed (are |
| always enabled), and would lead to infinitely running PLC code. Detection of |
| unrestricted events however, is incomplete. That is, for some unrestricted |
| the code generation results in an error, while for other unrestricted events |
| code is generated without any warnings or errors. See the |
| <a href="#tools-cif2plc-progbody">Program body</a> section for more information.</p> |
| </li> |
| <li> |
| <p>Specifications without automata are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates outside locations are not supported, except if it |
| can be determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>State invariants in components are not supported, except if it can be |
| determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>State/event exclusion invariants (in components as well as locations) are not |
| supported. To allow state/event exclusion invariants to be used in the input, |
| manually eliminate them first using the |
| <a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> CIF to CIF transformation.</p> |
| </li> |
| <li> |
| <p>Discrete variables with multiple initial values (including <code>any</code>) are not |
| supported.</p> |
| </li> |
| <li> |
| <p>External user-defined functions are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent locations are not supported.</p> |
| </li> |
| <li> |
| <p>Initialization predicates in locations that can not be statically evaluated |
| are not supported.</p> |
| </li> |
| <li> |
| <p>State invariants in locations are not supported, except if it can be |
| determined statically that they are trivially <code>true</code>.</p> |
| </li> |
| <li> |
| <p>Automata that do not have exactly one initial location are not supported.</p> |
| </li> |
| <li> |
| <p>Urgent edges are not supported.</p> |
| </li> |
| <li> |
| <p>User-defined functions without parameters are not supported.</p> |
| </li> |
| <li> |
| <p>Internal user-defined functions that contain a multi-assignment that assigns |
| multiple (non-overlapping) parts of a single variable are not supported. |
| For instance, <code>a[0], a[1] := 1, 2</code> is not supported, as multiple parts |
| (the first and second element) of array <code>a</code> are assigned in a single |
| multi-assignment. This restriction applies only to multi-assignments in |
| functions, not to multi-assignments on edges.</p> |
| </li> |
| <li> |
| <p>Internal user-defined functions that contain a <code>continue</code> statement are |
| not supported.</p> |
| </li> |
| <li> |
| <p>Data types other than <code>bool</code>, <code>int</code> (with or without range), <code>real</code>, |
| enumerations, tuples, and arrays, are not supported. This applies to the data |
| types of variables, parameters of functions, return types of functions, etc.</p> |
| </li> |
| <li> |
| <p>String values are not supported.</p> |
| </li> |
| <li> |
| <p>Cast from <code>int</code> to <code>real</code> and casts that don’t change the type, are |
| supported. All other casts are not supported.</p> |
| </li> |
| <li> |
| <p>Sampling of distributions is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the conjunction and disjunction binary operators on anything other |
| than boolean values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the equality and inequality binary operators on anything other |
| than boolean, integer, real, or enumeration values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the addition and subtraction binary operators on anything other |
| than integer or real values is not supported.</p> |
| </li> |
| <li> |
| <p>The use of the element test and subset binary operators is not supported.</p> |
| </li> |
| <li> |
| <p>Projection on anything other than tuples and arrays is not supported. This |
| applies to expressions as well as addressables (the left hand sides of |
| assignments). For arrays, both 0-based indices (counting from the left) as |
| well as negative indices (counting from the right) are supported.</p> |
| </li> |
| <li> |
| <p>Slicing is not supported.</p> |
| </li> |
| <li> |
| <p>Function calls on anything other than standard library functions and internal |
| user-defined functions is not supported.</p> |
| </li> |
| <li> |
| <p>The <code>ceil</code>, <code>del</code>, <code>empty</code>, <code>floor</code>, <code>fmt</code>, <code>pop</code>, <code>round</code>, |
| <code>scale</code>, <code>sign</code>, <code>size</code>, <code>acosh</code>, <code>asinh</code>, <code>atanh</code>, <code>cosh</code>, |
| <code>sinh</code>, and <code>tanh</code> standard library functions are not supported.</p> |
| </li> |
| <li> |
| <p>The distribution standard library functions are not supported.</p> |
| </li> |
| <li> |
| <p>Lists (except for arrays), sets, and dictionaries are not supported.</p> |
| </li> |
| <li> |
| <p>The use of functions as values is not supported. That is, functions may only |
| be used in function calls, and may for instance not be stored in variables.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-7">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> (if <em>Simplify values</em> option is enabled)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-others">Simplify others</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-consts">Eliminate constants</a> (if <em>Simplify values</em> option is enabled)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>After these preprocessing steps, the generator checks whether the specification |
| is supported. It then applies the following additional <a href="../../cif2cif/index.html">CIF to CIF |
| transformations</a>:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-linearize-merge">Linearize (merge)</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> (if <em>Simplify values</em> option is enabled)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-standard-compliance">Standard compliance</h5> |
| <div class="paragraph"> |
| <p>The PLC code that is generated complies with the second edition (from 2003) of |
| the IEC 61131-3 standard. The code does not use any vendor specific extensions, |
| functions, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the TwinCAT <a href="#tools-cif2plc-output-type">output type</a>, <code>STRUCT</code> |
| data type declarations have no <code>;</code> character after the <code>STRUCT</code> data types, |
| to work around a bug in the TwinCAT parser. In that case the output is not |
| compliant with the IEC 61131-3 standard.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-generated-plc-code">Generated PLC code</h5> |
| <div class="paragraph"> |
| <p>The bodies of the programs and functions in the generated PLC code use |
| Structured Text as programming language. Structured Text is one of the |
| programming languages that is part of the IEC 61131-1 standard.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The generated code contains a single program called <code>MAIN</code>. This program is |
| instantiated in a task, which is part of a resource, which in turn is part of |
| a configuration. The configuration is put in a project, but that is outside |
| the range of the IEC 61131-3 standard. Most implementations however, work with |
| projects. The effect of the project, configuration, resource, and task is |
| dependent on the <a href="#tools-cif2plc-output-type">output type</a>. Besides a |
| program, the code generator also generates data types, functions, and global |
| variables.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For algebraic variables, functions are generated that are parametrized over the |
| state of the system. Similarly, functions are generated for the derivatives of |
| the continuous variables. For the discrete and continuous variables (including |
| variable <code>time</code>), a <code>STRUCT</code> data type named <code>STATE</code> is generated that |
| holds the entire state of the system (or more precisely, the |
| <a href="#tools-cifsim-traces-state">state</a> of the CIF specification). For input variables, |
| an <code>INPUTS</code> global variables list/file is generated. For constants (if |
| <em>Simplify values</em> option is disabled), a <code>CONSTS</code> global variables list/file |
| is generated.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For invalid CIF specifications, the resulting code may not always behave as the |
| original CIF code. For instance, the ranges of integer types are ignored by the |
| code generator. Furthermore, <code>mod</code> by zero in CIF results in a runtime error, |
| while in the generated code it results in zero. Out of bound projection indices |
| of arrays may for instance have the effect that the closest existing element is |
| used instead, and the result may even be implementation dependent. There are |
| other such differences as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Little to no effort is put into generating readable code. That is, the |
| generated is not meant to be inspected. The generated code is also not intended |
| to be modified directly. Instead, the original CIF models should be modified, |
| and from them new PLC code should be generated. Examples of non-readable code |
| include the generated <a href="#tools-cif2plc-names">names</a>, and code generated |
| for expressions (which has way more parentheses than strictly necessary).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-names">Names</h5> |
| <div class="paragraph"> |
| <p>The generated PLC code will contain names for functions, variables, locations |
| of automata, etc. The absolute names of all objects are used. The names are |
| influenced by the <a href="#tools-cif2cif-chapter-linearize-merge">linearization</a> |
| algorithm. They are further influenced by the PLC code generator.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The code generator ensures unique names in the generated PLC code, taking into |
| account the reserved names (keywords, standard functions, etc) of the IEC |
| 61131-3 standard and some of the common implementations of that standard. To |
| avoid reserved names, names are prefixed with prefixes that depend on the type |
| of object (for instance, <code>dvar_</code> for discrete variables). Furthermore, it |
| takes into account that names in CIF are case sensitive, while they are case |
| insensitive in IEC 61131-3. The code generator computes a candidate name based |
| on these criteria.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If this results in duplicate names, renaming is performed. A common reason for |
| renaming is different locations (of the same automaton or of different |
| automata) that have the same name, but in different casing. For instance, |
| consider one location named <code>WaitForTimeout</code> and another named |
| <code>WaitForTimeOut</code>. After linearization, there is an enumeration with a literal |
| for each unique location name. The enumeration thus has at least two literals, |
| named <code>WaitForTimeout</code> and <code>WaitForTimeOut</code>. The candidate names for these |
| enumeration literals are <code>elit_WaitForTimeout</code> and <code>elit_WaitForTimeOut</code>. |
| However, they are identical except for casing. Thus, the first one that is |
| encountered during code generation gets the candidate name, and the second one |
| is renamed. This results in a warning like this:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="console">WARNING: PLC variable "elit_WaitForTimeout" is renamed to "elit_WaitForTimeout2".</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Renaming may be needed to ensure valid functioning output. However, it may make |
| it slightly more difficult to trace names in the generated PLC code back to the |
| original CIF model. Also, in the PLC environment, when debugging the current |
| values of variables may be shown. If enumeration literals are renamed, the |
| renamed names may then be shown in the debugger. By default, the PLC code |
| generator does not inform the user when renaming takes place. By enabling the |
| <em>Rename Warnings</em> option, a warning will be printed to the console, each time |
| a PLC name is renamed.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-progbody">Program body</h5> |
| <div class="paragraph"> |
| <p>The body of the <code>MAIN</code> program consists of several parts. The <code>MAIN</code> |
| program is executed exactly once per cycle, by the PLC. The following parts are |
| present, and are executed in order:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Time and cycle time handling.</p> |
| </li> |
| <li> |
| <p>Initialization of the initial state, for the first cycle only.</p> |
| </li> |
| <li> |
| <p>Updating of the continuous variables for the time that has passed since the |
| previous cycle, for all but the first cycle.</p> |
| </li> |
| <li> |
| <p>A loop that executes events for as long as they are possible.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The code automatically determines the cycle time that is used, in a manner that |
| does not require any vendor specific extensions, functions, or data types. |
| The generated code works for fixed cycle times (periodic task scheduling) as |
| well as variable cycle times (non-periodic tasks).</p> |
| </div> |
| <div class="paragraph"> |
| <p>During the first cycle, the variables of the state are initialized to their |
| proper values. For subsequent cycles, the state resulting from the previous |
| cycle is reused, where the values of the continuous variables are updated to |
| account for the time that has passed since the beginning of the previous cycle. |
| For details on the method used to update the values of the continuous |
| variables, see the <a href="#tools-cif2plc-accuracy">Accuracy over time</a> section.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The loop at the end of the body evaluates the guard of each of the events of |
| the CIF specification. If a guard holds, the corresponding update is performed. |
| Code is generated for the events, or rather the edges, in the order that they |
| occur in the <a href="#tools-cif2cif-chapter-linearize-merge">linearized</a> CIF |
| specification. Linearization is performed in such a way, that the PLC code that |
| is generated from it, has a correspondence to the simulator. Assuming the |
| simulator is used to simulate by always automatically choosing the |
| <a href="#tools-cifsim-input-chapter-automatic">first transition</a> that is enabled, the |
| PLC code will choose that same transition. That is, for each iteration of the |
| event loop, the code is executed for the first event with an enabled guard. |
| Then, a new iteration of the loop is started, from the top, to ensure that the |
| first enabled event is always executed, similar to simulation. If during an |
| iteration of the loop none of the events is enabled, the loop terminates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If at least one event was enabled, the loop is executed again. If during an |
| iteration of the loop none of the edges was enabled, the loop terminates. This |
| approach generally does not result in predictable execution times of the |
| program body. That is, if a certain edge keeps being enabled, the loop is |
| executed over an over again. In that case, the execution time of the body |
| exceeds the fixed cycle time, and the controller is no longer guaranteed to |
| work correctly. Even if the loop is only executed a finite number of times, |
| the execution time of the body may exceed the fixed cycle time. One may |
| consider monitoring the execution times to detect such issues.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| Within the 'event loop', a counter is used to detect how often the loop is |
| repeated. After the loop is executed a 100 times, the loop is terminated, to |
| ensure that the body terminates in the case of events that are always possible. |
| In such a cases, variable <code>loopsKilled</code> is incremented by one, for debugging. |
| While by default the loop is terminated after 100 iterations, this maximum |
| number of iterations can be configured using the |
| <b class="menuref">PLC maximum iterations</b> |
| option (<b class="menuref">Generator</b> |
| category). The |
| option can also be set to infinite, to not impose a restriction, and never |
| terminate the loop due to too many iterations. See also the |
| <a href="#tools-cif2plc-options">Options</a> section above.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Obviously, similar to the fact that the controller cannot guarantee its correct |
| behavior if the execution time of a cycle exceeds the cycle time, the |
| controller also cannot guarantee its correct behavior if the inputs from the |
| external I/O change more rapidly than the cycle time. That is, if an input |
| changes during a cycle, the change is not noticed until the next cycle. If an |
| input changes during a cycle and changes back during that same cycle, the |
| change is not noticed at all. Therefore, choosing an appropriate cycle time is |
| essential for the correct functioning of the controller.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-accuracy">Accuracy over time</h5> |
| <div class="paragraph"> |
| <p>The generated code maintains the running time in seconds, by adding the cycle |
| time to current running time, on each cycle. Due to the finite binary |
| representation of real values, this results in loss of a accuracy over |
| prolonged periods of execution time. As such, the use of variable <code>time</code> in |
| CIF models is highly discouraged.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, for a cycle time of one millisecond, while there may be loss of |
| accuracy, time should keep increasing for at least several thousand years. |
| After that, adding the cycle time may no longer increase the value of the |
| variable, potentially resulting in unexpected execution behavior.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The continuous variables from the CIF specification are updated each cycle |
| using the |
| <a href="http://en.wikipedia.org/wiki/Euler_method">Euler method</a> |
| for |
| integration. That is, each cycle the cycle time is multiplied by the derivative |
| of the continuous variable in the state of the previous cycle. This value is |
| added to the value of the continuous variable. Essentially, a linear |
| approximation of the derivative is used, calculated using the state of the |
| previous cycle.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The Euler method can be |
| <a href="http://en.wikipedia.org/wiki/Numerical_stability">numerically unstable</a>, |
| can suffer from rounding |
| errors due to the use finite binary representations of real values, and has |
| some other issues as well. The effects are likely to be limited if linear |
| continuous variable (continuous variables with constant derivatives) are used. |
| Especially clocks (derivative +1 or -1) generally don’t suffer too much from |
| these issues. However, even clocks may suffer from loss of accuracy over time. |
| As such, clocks should not be used to measure over long periods of time. |
| Instead they should be reset, rendering the past loss of accuracy irrelevant |
| for any future measurements.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-io-coupling">I/O coupling</h5> |
| <div class="paragraph"> |
| <p>For all variables in the state of the CIF specification, except for variable |
| <code>time</code>, PLC variables are generated with a <code>%Q*</code> address, to ensure they |
| can be used as output variables, and can potentially be coupled to output |
| ports. The state is maintained in a variable <code>state0</code>, a persistent local |
| variable of the <code>MAIN</code> program.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For all input variables of the CIF specification, a PLC variable is generated |
| with a <code>%I*</code> addresses, to ensure they can be used as input variables, and |
| can potentially be coupled to input ports. These variables are generated in a |
| global variables list/file named <code>INPUTS</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The actual coupling to hardware addresses is something that is left to the |
| implementation of the PLC programming environment.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-output-type">PLC output type</h5> |
| <div class="paragraph"> |
| <p>The PLC code generator can generate its output in multiple forms (file formats) |
| depending on the output type. The output type can be configured using the |
| <b class="menuref">PLC code output type</b> |
| option ( |
| <b class="menuref">Generator</b> |
| category). The |
| following output types are currently available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>PLCopen XML (default)</p> |
| </li> |
| <li> |
| <p>IEC 61131-3</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2plc-chapter-twincat">TwinCAT</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>PLCopen XML is an |
| <a href="http://en.wikipedia.org/wiki/XML">XML</a>-based file format |
| standardized by the PLCopen organization, intended for the exchange of complete |
| projects of PLC code, even across different tools and vendors. The PLCopen |
| XML files generated by the PLC code generator are compliant with version 2.01 |
| of the PLCopen XML standard. By default, if no output file is specified, it |
| defaults to the input file path, where the <code>.cif</code> file extension is removed |
| (if present), and a <code>.plcopen.xml</code> file extension is added.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Output in IEC 61131-3 syntax generates multiple files. By default, if no output |
| directory is specified, it defaults to the input file path, where the <code>.cif</code> |
| file extension is removed (if present), and a <code>_plc</code> directory extension is |
| added. The <code>MAIN</code> program gets a <code>.plcprog</code> file extension, functions get |
| a <code>.plcfunc</code> file extension, type declarations get a <code>.plctype</code> file |
| extension, and the configuration gets a <code>.plccfg</code> file extension. The |
| <em>PLC project name</em> and <em>PLC resource name</em> options have no effect for this |
| output type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>TwinCAT is a complete |
| <a href="http://en.wikipedia.org/wiki/Integrated_development_environment">IDE</a> |
| for the |
| development and testing of PLC controllers. Using the TwinCAT PLC output type, |
| the generated PLC code can be written to the native file formats of the TwinCAT |
| IDE. By default, if no output directory is specified, it defaults to the input |
| file path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>_twincat</code> directory extension is added. See the |
| <a href="#tools-cif2plc-chapter-twincat">TwinCAT PLC output</a> page for further details.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2plc-chapter-twincat">TwinCAT PLC output</h5> |
| <div class="paragraph"> |
| <p> |
| |
| <a href="http://www.beckhoff.com/english/twincat">TwinCAT</a> |
| is a complete |
| <a href="http://en.wikipedia.org/wiki/Integrated_development_environment">IDE</a> |
| for the |
| development and testing of PLC controllers. Using the TwinCAT <a href="#tools-cif2plc-output-type">PLC output |
| type</a>, the generated PLC code can be written to the |
| native file formats of the TwinCAT IDE. This allows for more tight integration |
| and smoother development cycles than using the PLCopen XML output type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>We currently only provide official support for version 3.1 of TwinCAT.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2plc-twincat-modes">TwinCAT system modes</h6> |
| <div class="paragraph"> |
| <p>The TwinCAT software IDE is built on Microsoft Visual Studio. TwinCAT also |
| supplies a utility to monitor and control the TwinCAT System Service, via an |
| icon in the system tray, part in the Windows taskbar. The icon shows the mode |
| (or status) of the TwinCAT system:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_inactive.png" alt="mode inactive"></span> |
| Inactive Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_stop.png" alt="mode stop"></span> |
| Stop Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_config.png" alt="mode config"></span> |
| Config Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_run.png" alt="mode run"></span> |
| Run Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_ex.png" alt="mode ex"></span> |
| Exception Mode</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In the <em>Inactive Mode</em>, the TwinCAT System Service is not running. Restart |
| Windows or manually activate the TwinCAT System Service and related services.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The <em>Stop Mode</em> is of little use, so |
| <a href="#tools-cif2plc-twincat-modes-change">switch</a> to the <em>Config Mode</em> |
| instead. In the <em>Config Mode</em>, the system (the PLC) can be configured. In the |
| <em>Run Mode</em>, the system (the PLC) can be used to control the hardware. If a |
| runtime exception occurs in <em>Run Mode</em>, the <em>Exception Mode</em> becomes active.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Within Visual Studio, the mode is also shown as an icon in the bottom right |
| corner of the IDE:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_stop.png" alt="mode stop"></span> |
| Stop Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_config.png" alt="mode config"></span> |
| Config Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_run.png" alt="mode run"></span> |
| Run Mode</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_run.png" alt="mode run"></span> / <span class="image"><img src="./tools/cif2plc/mode_free_run.png" alt="mode free run"></span> |
| Free Run Mode (alternating icons)</p> |
| </li> |
| <li> |
| <p><span class="image"><img src="./tools/cif2plc/mode_ex.png" alt="mode ex"></span> |
| Exception Mode</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If the system is only equipped with a <em>soft PLC</em>, and the TwinCAT environment |
| is set up to target the local system, both icons should indicate a consistent |
| status. This page assumes this situation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2plc-twincat-modes-change">Changing modes</h6> |
| <div class="paragraph"> |
| <p>To change to <em>Config Mode</em> or restart <em>Config Mode</em> from the system tray:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Right click the system tray icon and choose |
| <span class="menuseq"><b class="menu">System</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Config</b></span>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>To change to <em>Config Mode</em> or restart <em>Config Mode</em> from Visual Studio:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Restart TwinCAT (Config Mode)</b></span>. |
| Alternatively, click the appropriate toolbar item |
| (<span class="image"><img src="./tools/cif2plc/restart_config.png" alt="restart config"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Restart TwinCAT System in Config Mode</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question <em>Load I/O Devices</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question <em>Activate Free Run</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>To change to <em>Run Mode</em> or restart <em>Run Mode</em> from the system tray:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Make sure the hardware is powered up.</p> |
| </li> |
| <li> |
| <p>Right click the system tray icon and choose |
| <span class="menuseq"><b class="menu">System</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Start/Restart</b></span>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>To change to <em>Run Mode</em> or restart <em>Run Mode</em> from Visual Studio:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Make sure the hardware is powered up.</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Restart TwinCAT System</b></span>. Alternatively, |
| click the appropriate toolbar item (<span class="image"><img src="./tools/cif2plc/restart_run.png" alt="restart run"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question <em>Restart TwinCAT System in Run Mode</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In general it is recommended to switch modes via Visual Studio instead of via |
| the system tray icon.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-generated-output">Generated output</h6> |
| <div class="paragraph"> |
| <p>The CIF PLC code generator can generate code into an existing TwinCAT Visual |
| Studio solution, with a TwinCAT XAE project that contains a TwinCAT Standard |
| PLC project. The directory that contains the solution must have the same name |
| (except for the file extension) as the solution file (<code>.sln</code> file). The |
| TwinCAT XAE project (both the directory and the <code>.tsproj</code> file) in the |
| solution should have the same name as well. The TwinCAT XAE project should |
| contain a TwinCAT Standard PLC project. This project may be given any name, |
| and this name can be configured using the |
| <b class="menuref">PLC project name</b> |
| option |
| (<b class="menuref">Generator</b> |
| category). However, in order to be able to import I/O |
| mappings it is highly recommended to always use the default name suggested by |
| TwinCAT (<code>Untitled1</code>) for TwinCAT Default PLC projects.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The project should already contain a task. This task can be given any name, |
| and this name can be configured using the |
| <b class="menuref">PLC task name</b> |
| option |
| (<b class="menuref">Generator</b> |
| category). By default, TwinCAT Default PLC projects have |
| a task named <code>PlcTask</code>. This name is the default for the |
| <b class="menuref">PLC task name</b> |
| option as well. The cycle time and priority of the |
| task are automatically updated by the PLC code generator, depending on the |
| values provided for the options of the generator. The code generator also |
| ensures that the <code>MAIN</code> program is instantiated/scheduled on the task.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All <code>POU</code> (functions, programs, etc), <code>DUT</code> (data types), and <code>GVL</code> |
| (global variable lists) code files that are present in the TwinCAT Default PLC |
| project are removed, from both the project and from disk, by the PLC code |
| generator. The newly generated code files are (over)written, and the project is |
| updated to include and compile only the newly generated files.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The |
| <b class="menuref">PLC configuration name</b> |
| and |
| <b class="menuref">PLC resource name</b> |
| options have no effect on the TwinCAT output.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2plc-twincat-usage">TwinCAT usage</h6> |
| <div class="paragraph"> |
| <p>Follow these steps to create a solution and project in TwinCAT, generate PLC |
| code in it, and use the PLC code to control the hardware:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Start TwinCAT (Visual Studio) by right clicking on the TwinCAT system tray |
| icon and choosing |
| <b class="menuref">TwinCAT XAE (VS 2010)</b>.</p> |
| </li> |
| <li> |
| <p>Create a new TwinCAT XAE project:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">New</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Project…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In the |
| <b class="menuref">New Project</b> |
| window, |
| <b class="menuref">TwinCAT XAE Project (XML format)</b> |
| should already be selected. If not, first select |
| <b class="menuref">TwinCAT Project</b> |
| on the left (from the list of |
| <b class="menuref">Installed Templates</b>), |
| and then select |
| <b class="menuref">TwinCAT XAE Project (XML format)</b>.</p> |
| </li> |
| <li> |
| <p>Choose a project name and enter it in the |
| <b class="menuref">Name</b> |
| box at the |
| bottom of the dialog.</p> |
| </li> |
| <li> |
| <p>Make sure the |
| <b class="menuref">Solution name</b> |
| is exactly the same, and that the |
| <b class="menuref">Create directory for solution</b> |
| option is enabled.</p> |
| </li> |
| <li> |
| <p>For |
| <b class="menuref">Location</b>, |
| select the directory in which the directory for |
| the solution should be created. This is usually the directory that contains |
| the script and/or source files you will be using to generate the PLC code.</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>To figure out the directory that contains the ToolDef script, make sure |
| that the <b class="menuref">Properties</b> view is visible in Eclipse. Select the ToolDef |
| script in the 'Project Explorer' tab or 'Package Explorer' tab, and look |
| for the <b class="menuref">location</b> property.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Click |
| <b class="button">OK</b> |
| to create the project.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Scan the available hardware:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Make sure the hardware is powered up.</p> |
| </li> |
| <li> |
| <p>Make sure the <a href="#tools-cif2plc-twincat-modes">Config Mode</a> is enabled, |
| by <a href="#tools-cif2plc-twincat-modes-change">switching</a> to it if it is not |
| the current mode.</p> |
| </li> |
| <li> |
| <p>In the project, under |
| <b class="menuref">I/O</b>, |
| right click the |
| <b class="menuref">Devices</b> |
| item and choose |
| <b class="menuref">Scan</b>. |
| Alternatively, select the |
| <b class="menuref">I/O</b> |
| item and click the appropriate toolbar item (<span class="image"><img src="./tools/cif2plc/scan_devices.png" alt="scan devices"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the warning |
| <em>HINT: Not all types of devices can be found automatically</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up where you have to choose the I/O device to scan. Normally, |
| if you have only one I/O device, it should already be selected. Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question <em>Scan for boxes</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question <em>Activate Free Run</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Create a new TwinCAT PLC project:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Right click the |
| <b class="menuref">PLC</b> |
| item in the project, and choose |
| <b class="menuref">Add New Item…​</b>.</p> |
| </li> |
| <li> |
| <p>In the |
| <b class="menuref">Add New Item</b> |
| dialog, |
| <b class="menuref">Standard PLC project</b> |
| should already be selected.</p> |
| </li> |
| <li> |
| <p>Keep the name |
| <code>Untitled1</code> |
| in the |
| <b class="menuref">Name</b> |
| box at the |
| bottom of the dialog.</p> |
| </li> |
| <li> |
| <p>Also don’t change the |
| <b class="menuref">Location</b> |
| of the project.</p> |
| </li> |
| <li> |
| <p>Click |
| <b class="menuref">Add</b> |
| to add the PLC project.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Save the entire solution by clicking <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Save All</b></span>.</p> |
| </li> |
| <li> |
| <p>Generate PLC code. If using a script, wait for the execution of the script to |
| finish (the status indicated |
| as part of the title of the console should change from <code>running</code> to |
| <code>FINISHED</code>).</p> |
| </li> |
| <li> |
| <p>Switch back to TwinCAT (Microsoft Visual Studio).</p> |
| </li> |
| <li> |
| <p>When a |
| <em>File Modification Detected</em> |
| window pops up for the project, |
| click |
| <b class="button">Reload</b> |
| to reload the updated project that was written by |
| the CIF tooling.</p> |
| </li> |
| <li> |
| <p>Build the project by clicking <span class="menuseq"><b class="menu">Build</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Rebuild Solution</b></span>.</p> |
| </li> |
| <li> |
| <p>Load the I/O mappings:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In the project, under |
| <b class="menuref">I/O</b>, |
| right click |
| <b class="menuref">Mappings</b>, |
| and choose |
| <b class="menuref">Import Mapping Infos…​</b>.</p> |
| </li> |
| <li> |
| <p>Select the mappings file for your hardware, and click |
| <b class="menuref">Open</b>.</p> |
| </li> |
| <li> |
| <p>If the import succeeds, you should see an |
| <em>Untitled1 Instance - …​</em> |
| item under the |
| <b class="menuref">Mappings</b> |
| item.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Activate the configuration:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Activate Configuration</b></span>. Alternatively, |
| click the appropriate toolbar item (<span class="image"><img src="./tools/cif2plc/activate_cfg.png" alt="activate cfg"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Activate Configuration (Old Configurations will be overwritten!)</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Restart TwinCAT System in Run Mode</em>. Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Start the PLC:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Login</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/login.png" alt="login"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Application Port_851 does not |
| exist on the device. Do you want to create it and proceed with download?</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Start</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/start.png" alt="start"></span>).</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>The PLC is now running, and you can use the system.</p> |
| </li> |
| </ul> |
| </div> |
| <div id="tools-cif2plc-twincat-usage-stop" class="paragraph"> |
| <p>To stop the PLC:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Stop</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/stop.png" alt="stop"></span>).</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Logout</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/logout.png" alt="logout"></span>). This step is optional, and can usually be |
| skipped.</p> |
| </li> |
| </ul> |
| </div> |
| <div id="tools-cif2plc-twincat-usage-reset" class="paragraph"> |
| <p>To reset the PLC and start the 'simulation' from the beginning, with the same |
| code and the same configuration:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Make sure the hardware is powered up.</p> |
| </li> |
| <li> |
| <p>Load the I/O mappings, if the |
| <em>Untitled1 Instance - …​</em> |
| item under the |
| <b class="menuref">Mappings</b> |
| item is no longer present:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In the project, under |
| <b class="menuref">I/O</b>, |
| right click |
| <b class="menuref">Mappings</b>, |
| and choose |
| <b class="menuref">Import Mapping Infos…​</b>.</p> |
| </li> |
| <li> |
| <p>Select the mappings file for your hardware, and click |
| <b class="menuref">Open</b>.</p> |
| </li> |
| <li> |
| <p>If the import succeeds, you should see an |
| <em>Untitled1 Instance - …​</em> |
| item under the |
| <b class="menuref">Mappings</b> |
| item.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Reactivate the configuration:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Activate Configuration</b></span>. Alternatively, |
| click the appropriate toolbar item (<span class="image"><img src="./tools/cif2plc/activate_cfg.png" alt="activate cfg"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Activate Configuration (Old Configurations will be overwritten!)</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Restart TwinCAT System in Run Mode</em>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Start the PLC:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Login</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/login.png" alt="login"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Application Port_851 does not |
| exist on the device. Do you want to create it and proceed with download?</em>. |
| Click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Start</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/start.png" alt="start"></span>).</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>The PLC is now running, and you can use the system.</p> |
| </li> |
| </ul> |
| </div> |
| <div id="tools-cif2plc-twincat-usage-regen" class="paragraph"> |
| <p>Whenever you change a CIF source file, regenerate a supervisor, change a |
| hardware mapping, etc, you need to regenerate the PLC code as well. Follow |
| these steps:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Make sure the <a href="#tools-cif2plc-twincat-modes">Config Mode</a> is enabled, |
| by <a href="#tools-cif2plc-twincat-modes-change">switching</a> to it if it is not |
| the current mode.</p> |
| </li> |
| <li> |
| <p>Save the entire solution in TwinCAT by clicking |
| <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Save All</b></span>.</p> |
| </li> |
| <li> |
| <p>Regenerate PLC code from Eclipse. |
| If using a script, wait for the execution of the script to finish (the status indicated |
| as part of the title of the console should change from <code>running</code> to |
| <code>FINISHED</code>).</p> |
| </li> |
| <li> |
| <p>Switch back to TwinCAT (Microsoft Visual Studio).</p> |
| </li> |
| <li> |
| <p>For all |
| <em>File has been changed outside the environment. Reload the new file?</em> |
| questions, click |
| <b class="button">Yes</b> |
| or press |
| <kbd>ENTER</kbd>. |
| See the |
| <a href="#tools-cif2plc-twincat-faq">Frequently Asked Questions (FAQ)</a> for instructions on how to disable some of |
| these questions.</p> |
| </li> |
| <li> |
| <p>When a |
| <em>File Modification Detected</em> |
| window pops up for the project, |
| click |
| <b class="button">Reload</b> |
| to reload the updated project that was written by |
| the CIF tooling.</p> |
| </li> |
| <li> |
| <p>Clean the project by clicking <span class="menuseq"><b class="menu">Build</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Clean Solution</b></span>.</p> |
| </li> |
| <li> |
| <p>Rebuild the project by clicking <span class="menuseq"><b class="menu">Build</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Rebuild Solution</b></span>.</p> |
| </li> |
| <li> |
| <p>Make sure the hardware is powered up.</p> |
| </li> |
| <li> |
| <p>Reload the I/O mappings:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In the project, under |
| <b class="menuref">I/O</b>, right click |
| <b class="menuref">Mappings</b>, |
| and choose |
| <b class="menuref">Import Mapping Infos…​</b>.</p> |
| </li> |
| <li> |
| <p>Select the mappings file for your hardware, and click |
| <b class="menuref">Open</b>.</p> |
| </li> |
| <li> |
| <p>If the import succeeds, you should see an |
| <em>Untitled1 Instance - …​</em> |
| item under the |
| <b class="menuref">Mappings</b> |
| item.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Activate the configuration:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Activate Configuration</b></span>. Alternatively, |
| click the appropriate toolbar item (<span class="image"><img src="./tools/cif2plc/activate_cfg.png" alt="activate cfg"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Activate Configuration (Old Configurations will be overwritten!)</em>. Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <b class="menuref">Restart TwinCAT System in Run Mode</b>. |
| Click |
| <b class="button">OK</b> |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Start the PLC:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Login</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/login.png" alt="login"></span>).</p> |
| </li> |
| <li> |
| <p>A dialog pops up with the question |
| <em>Application Port_851 does not |
| exist on the device. Do you want to create it and proceed with download?</em>. |
| Click |
| btn:Yes[] |
| or press |
| <kbd>ENTER</kbd>.</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">PLC</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Start</b></span>. Alternatively, click the appropriate |
| toolbar item (<span class="image"><img src="./tools/cif2plc/start.png" alt="start"></span>).</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>The PLC is now running, and you can use the system.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2plc-twincat-faq">Frequently Asked Questions (FAQ)</h6> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><strong>Question</strong>: Is there something that can be done about the large number of |
| <em>File has been changed outside the environment…​</em> prompts?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: Yes. Click <span class="menuseq"><b class="menu">Tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Options…​</b></span> to show the |
| <b class="menuref">Options</b> dialog. On the left, select |
| <span class="menuseq"><b class="menu">Environment</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Documents</b></span>. Then, on the right, enable the |
| <b class="menuref">Detect when file is changed outside the environment</b> and |
| <b class="menuref">Auto-load changes, if saved</b> options.</p> |
| </div> |
| </li> |
| <li> |
| <p><strong>Question</strong>: Why doesn’t importing the I/O mappings have any effect?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: Make sure the TwinCAT Standard PLC project is named |
| <code>Untitled1</code>, and try again. Also, make sure you’ve built the |
| solution before you try to import the I/O mappings.</p> |
| </div> |
| </li> |
| <li> |
| <p><strong>Question</strong>: I get a dialog with the warning |
| <em>Device '…​' needs a sync master (at least one variable linked to a task variable)</em>. |
| What should I do?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: You probably forgot to load an I/O mapping.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div id="tools-cif2plc-twincat-faq-inlinemon" class="ulist"> |
| <ul> |
| <li> |
| <p><strong>Question</strong>: Why does opening the MAIN program take so long in |
| Run Mode?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: As the generated code becomes larger, it can take a long time for |
| TwinCAT to set up the environment for inline monitoring of the MAIN |
| program. To disable inline monitoring, click |
| <span class="menuseq"><b class="menu">Tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Options…​</b></span> to show the <b class="menuref">Options</b> dialog. |
| On the left, select |
| <span class="menuseq"><b class="menu">TwinCAT</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">PLC Environment</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Text Editor</b></span>. Then, on the |
| right, switch to the <b class="menuref">Monitoring</b> tab. Disable the |
| <b class="menuref">Enable inline monitoring option</b>.</p> |
| </div> |
| </li> |
| <li> |
| <p><strong>Question</strong>: TwinCAT hangs for long periods of time, before crashing and |
| automatically being restarted by Windows. What should I do?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: If the generated code is too large, TwinCAT may not be able to |
| handle it. In such cases, reduce the size of the generated code, by reducing |
| the size of the CIF model for which you are generating the code.</p> |
| </div> |
| </li> |
| <li> |
| <p><strong>Question</strong>: I get an error stating 'Reading file failed. […​]'. |
| What should I do?</p> |
| <div class="paragraph"> |
| <p><strong>Answer</strong>: The generated code is too large for TwinCAT to handle. See also |
| the answer to the previous question.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-miscellaneous-tools">Miscellaneous tools</h3> |
| <div class="sect3"> |
| <h4 id="tools-cif2cif-chapter-index">CIF to CIF transformer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF to CIF transformer can be used to syntactically transform CIF |
| specifications to similar CIF specifications, which behave in the same |
| manner (are semantically equivalent), but are expressed using different |
| language constructs. For example, the CIF to CIF transformation that |
| eliminates constants, replaces all uses of constants by their values, |
| and removes the constants from the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>These reusable transformations are primarily used to increase the subset |
| of CIF specifications that can be transformed or processed. |
| Usually, there is no need to apply the CIF to CIF transformations manually. |
| Transformations that work on subsets of the CIF language, automatically |
| apply the necessary CIF to CIF transformations as a preprocessing step, to |
| increase the translatable subset.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF to CIF transformer can also be used as a <a href="#tools-cif2cif-pprinter">pretty printer</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-6">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The transformation can be started from Eclipse in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Right click a <code>.cif</code> file in the 'Project Explorer' tab or |
| 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply CIF to CIF transformations…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Apply CIF to CIF transformations…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2cif</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cif2cif</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-options-19">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative local file system path to the |
| input CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, the output file path defaults to |
| the input file path, where the <code>.cif</code> file extension is removed (if |
| present), and a <code>.transformed.cif</code> file extension is added.</p> |
| </li> |
| <li> |
| <p><em>Transformations</em>: The CIF to CIF transformations to apply. The |
| transformations are applied in the chosen order. Transformations may be |
| applied multiple times. By default, no transformations are applied, |
| essentially making the CIF to CIF transformer a <a href="#tools-cif2cif-pprinter">pretty printer</a>.</p> |
| <div class="paragraph"> |
| <p>In the option dialog, the available transformations are shown. To add a |
| transformation, double click it, or select it and click the <em>Add</em> |
| button below the list of available transformations. To remove a |
| transformation, double click on it in the list of chosen transformations, or |
| select it in that list and click the <em>Remove</em> button.</p> |
| </div> |
| <div class="paragraph"> |
| <p>At the command line, specify comma separated transformation names, in the |
| order they should be applied. The names to use are listed below, in the |
| <a href="#tools-cif2cif-available">Available transformations</a> section.</p> |
| </div> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-transformation-descriptions">Transformation descriptions</h5> |
| <div class="paragraph"> |
| <p>The pages describing the <a href="#tools-cif2cif-available">available transformations</a> all use the same format. They have the following |
| sections:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Introduction</em>: describes the transformation in a few sentences.</p> |
| </li> |
| <li> |
| <p><em>Supported specifications</em>: describes the subset of CIF specifications to which |
| the transformation can be applied.</p> |
| </li> |
| <li> |
| <p><em>Preprocessing</em>: specifies the CIF to CIF transformations that are |
| automatically applied as preprocessing, or the CIF to CIF transformations |
| that can be manually applied as preprocessing, to increase the subset of |
| CIF specifications that can be transformed by the transformation.</p> |
| </li> |
| <li> |
| <p><em>Implementation details</em>: further specifies what the transformation does, how |
| it does it, and what the result of the transformation is. Most |
| transformations also show one or more examples.</p> |
| </li> |
| <li> |
| <p><em>Renaming</em>: explains if and when renaming may be performed by the |
| transformation.</p> |
| </li> |
| <li> |
| <p><em>Size considerations</em>: describes whether the transformation reduces or |
| increases the size of the specification. If the specification may increase |
| in size, an estimate of the order of increase is given (linear, exponential, |
| etc). Note that the size is not the file size, but rather the number of |
| objects used to represent the specification (the number of automata, |
| locations, edges, guards, binary operators, etc).</p> |
| </li> |
| <li> |
| <p><em>Optimality</em>: describes why the transformation result may not be optimal, if |
| applicable. May also explain how to eliminate certain concepts that may be |
| introduced as the result of the transformation.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-available">Available transformations</h5> |
| <div class="paragraph"> |
| <p>A whole collection of CIF to CIF transformations is available. The available |
| transformations are listed below, with a link to the information about the |
| transformation, and the name to use for that transformation on the command |
| line.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a> (<code>add-default-init-values</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-alg-vars">Eliminate algebraic variables</a> (<code>elim-alg-vars</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-aut-casts">Eliminate automata to string casts</a> (<code>elim-aut-casts</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a> (<code>elim-comp-def-inst</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-consts">Eliminate constants</a> (<code>elim-consts</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a> (<code>elim-enums</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-equations">Eliminate equations</a> (<code>elim-equations</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-groups">Eliminate groups</a> (<code>elim-groups</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-if-updates">Eliminate <code>if</code> updates</a> (<code>elim-if-updates</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> (<code>elim-locs-in-exprs</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-monitors">Eliminate monitors</a> (<code>elim-monitors</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a> (<code>elim-self</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</a> (<code>elim-state-event-excl-invs</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-tau-event">Eliminate <code>tau</code> event</a> (<code>elim-tau-event</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-tuple-field-projs">Eliminate tuple field projections</a> (<code>elim-tuple-field-projs</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-type-decls">Eliminate type declarations</a> (<code>elim-type-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-lift-events">Lift events</a> (<code>lift-events</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-linearize-merge">Linearize (merge)</a> (<code>linearize-merge</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-linearize-product">Linearize (product)</a> (<code>linearize-product</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-merge-enums">Merge enumerations</a> (<code>merge-enums</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-print-file-into-decls">Push print file declarations into print declarations</a> (<code>print-file-into-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-cif-svg-decls">Remove CIF/SVG declarations</a> (<code>remove-cif-svg-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a> (<code>remove-io-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-print-decls">Remove print declarations</a> (<code>remove-print-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-pos-info">Remove position information</a> (<code>remove-pos-info</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-reqs">Remove requirements</a> (<code>remove-reqs</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-others">Simplify others</a> (<code>simplify-others</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> (<code>simplify-values</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values-optimized">Simplify values (optimized)</a> (<code>simplify-values-optimized</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values-no-refs">Simplify values (no references)</a> (<code>simplify-values-no-refs</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</a> (<code>simplify-values-no-refs-optimized</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-svg-file-into-decls">Push SVG file declarations into other CIF/SVG declarations</a> (<code>svg-file-into-decls</code>)</p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-switches-to-ifs">Convert <code>switch</code> expressions to <code>if</code> expressions</a> (<code>switches-to-ifs</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-pprinter">Pretty printer</h5> |
| <div class="paragraph"> |
| <p>If no transformations are applied by the CIF to CIF transformer, the input CIF |
| specification is just read from the input file, validated, and written to the |
| output file. This can be useful, as it essentially turns the CIF to CIF |
| transformer into a CIF <em>pretty printer</em>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As a side effect of reading the input file and validating it, the model may |
| change slightly. In fact, this occurs not only for the CIF to CIF transformer |
| but for all tools, as they all read input files and validate them, before |
| continuing with their actual task. Examples of such changes include the |
| elimination of imports, the loss of comments, and the evaluation of tuple |
| projection indices.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-add-default-init-values">Add default initial values</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation adds the default initial values to variables |
| that are not given an explicit initial value. This includes discrete and |
| continuous variables, as well as local variables of functions.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-11">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-8">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details">Implementation details</h6> |
| <div class="paragraph"> |
| <p>The default values for all types are simple values. The only exception are |
| function types, for which a new function is introduced. This new functions |
| returns the default value for the return type of the function. If multiple |
| default values for the same function type are needed, the newly introduced |
| function is reused. The functions are named <code>_f</code>, <code>_f2</code>, <code>_f3</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton x: |
| disc int x, y = 5; |
| disc func bool (int) f; |
| location; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">func bool _f(int p0): |
| return false; |
| end |
| |
| automaton x: |
| disc int x = 0, y = 5; |
| disc func bool (int) f = _f; |
| location; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming">Renaming</h6> |
| <div class="paragraph"> |
| <p>If the names of the functions that are introduced, conflict with already |
| existing declarations, they are renamed. For instance, if <code>_f2</code> is already in |
| use, <code>_f22</code>, <code>_f23</code>, etc, are used instead. If renaming takes place, a |
| warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since values are added, this transformation increases the size of the |
| specification. For an array of 400 elements, with an array of 300 integers |
| each, the default initial value consists of 1,200 integers. Add such an initial |
| value can significantly increase the size of the model.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality">Optimality</h6> |
| <div class="paragraph"> |
| <p>The default values for all types are as primitive as they can be, and can |
| usually not be simplified any further. It may however be possible that |
| functions are introduced for the default values of function types, while such |
| a function already existed in the original specification.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-switches-to-ifs">Convert <code>switch</code> expressions to <code>if</code> expressions</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation converts <code>switch</code> expressions to <code>if</code> |
| expressions.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-12">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-9">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-2">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All <code>switch</code> expressions are replaced by <code>if</code> expressions. For instance, |
| consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg int y = ... |
| alg real x = switch y: |
| case 1: 1.0 |
| case 2: 4.0 |
| case 3: 9.0 |
| else 0.0 |
| end; |
| alg real z = switch y: |
| else 1.0 |
| end; |
| |
| automaton a: |
| alg string v = switch self: |
| case l1: "first" |
| case l2: "second" |
| end; |
| |
| location l1: |
| initial; |
| edge tau goto l2; |
| |
| location l2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is transformed to the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg int y = ... |
| alg real x = if y = 1: 1.0 |
| elif y = 2: 4.0 |
| elif y = 3: 9.0 |
| else 0.0 |
| end; |
| alg real z = 1.0; |
| |
| automaton a: |
| alg string v = if l1: "first" |
| else "second" |
| end; |
| |
| location l1: |
| initial; |
| edge tau goto l2; |
| |
| location l2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For algebraic variable <code>z</code>, there is only one case (the <code>else</code>), so no |
| <code>if</code> expression is generated. This optimization means that the control value |
| (<code>y</code> in this case) is lost.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For algebraic variable <code>v</code> in automaton <code>a</code>, the <code>switch</code> expression uses |
| an automaton self reference. The cases list the possible locations of the |
| automaton, and the <code>switch</code> expression maps them to string values. Since for |
| <code>if</code> expressions the <code>else</code> part is mandatory, the last <code>case</code> of the |
| <code>switch</code> is converted to the <code>else</code> of the <code>if</code> expression.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-2">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-2">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The created <code>if</code> expression is usually larger than the original <code>switch</code> |
| expression, as the control value is duplicated for each <code>if</code> and <code>elif</code> |
| part, where it is compared to the <code>case</code> values. For <code>switch</code> expressions |
| with only one <code>case</code> or <code>else</code>, no <code>if</code> expression is generated, and the |
| expression becomes smaller.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-2">Optimality</h6> |
| <div class="paragraph"> |
| <p>This transformation transforms <code>switch</code> expressions to <code>if</code> expressions, |
| leading to <code>if</code> expressions with <code>if</code> and <code>elif</code> guards that may not be |
| optimal. To simplify the result, apply additional CIF to CIF transformations, |
| such as <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-alg-vars">Eliminate algebraic variables</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates algebraic variables and their |
| equations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also: <a href="#tools-cif2cif-chapter-equations">Eliminate equations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-13">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| <li> |
| <p>Automaton <code>self</code> references are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-10">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-3">Implementation details</h6> |
| <div class="paragraph"> |
| <p>For each algebraic variable with a single equation in a component or automaton, |
| all uses of the variable (for instance in guards, invariants, etc) are |
| replaced by the value of the variable (the right hand side of its equation). |
| For algebraic variables with equations specified in the locations of an |
| automaton, an 'if' expression is created. This 'if' expression uses the |
| locations of the automaton as guards, and the right hand sides of the equations |
| as values for each of the alternatives. The last alternative is an 'else', and |
| thus has no guard. If the automaton has only one location, generation of the |
| 'if' expression is suppressed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The algebraic variables and their equations are removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg bool b1 = true; |
| alg bool b2; |
| equation b2 = false; |
| |
| automaton aut: |
| alg int a; |
| location l1: |
| equation a = 1; |
| location l2: |
| equation a = 2; |
| end |
| |
| invariant b1 or b2 or p.a > 0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton aut: |
| location l1; |
| location l2; |
| end |
| |
| invariant true or false or if p.l1: 1 else 2 end > 0;</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-3">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-3">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since algebraic variables are shortcuts for expressions, eliminating them |
| could result in an increase of the size of the specification. Algebraic |
| variables may be defined in terms of other algebraic variables. Therefore, in |
| the worst case, the increase is exponential.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-3">Optimality</h6> |
| <div class="paragraph"> |
| <p>For an assignment <code>x := 1 + y</code>, where <code>y</code> is an algebraic variable that is |
| eliminated, and where <code>y</code> has value <code>5</code>, the resulting assignment is |
| <code>x := 1 + 5</code>. The result is not simplified any further. To further simplify |
| the result, apply additional CIF to CIF transformations, such as |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation introduces 'if' expressions for algebraic variables |
| that have an equation per location, for automata with at least two locations. |
| The guards of such 'if' expressions refer to the locations of the automata. |
| To eliminate such location references, apply the |
| <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-aut-casts">Eliminate automata to string casts</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates casts of automata to strings.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-14">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-11">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-4">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All casts of automata to strings, using either implicit automaton <code>self</code> |
| references or explicit automata references, are eliminated. If the referred |
| automaton has only a single location, the cast is replaced by a string literal |
| with the name of that location. If the automaton has multiple locations, the |
| cast is replaced by an <code>if</code> expression, using the locations of the automaton |
| as guards, and string literals containing the location names as values. For |
| nameless locations the string literal <code>"*"</code> is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| alg string x = <string>self; |
| |
| location: |
| initial; |
| end |
| |
| automaton b: |
| alg string x = <string>self; |
| |
| location l1: |
| initial; |
| location l2: |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is transformed to the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| alg string x = "*"; |
| |
| location: |
| initial; |
| end |
| |
| automaton b: |
| alg string x = if l1: "l1" |
| elif l2: "l2" |
| else "l3" |
| end; |
| |
| location l1: |
| initial; |
| location l2; |
| location l3; |
| end</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-4">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-4">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The created <code>if</code> expressions are usually larger than the original cast |
| expressions. The increase is linear in terms of the number of locations times |
| the number of casts.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-4">Optimality</h6> |
| <div class="paragraph"> |
| <p>This transformation introduces 'if' expressions for automaton to string casts, |
| for automata with at least two locations. The guards of such 'if' expressions |
| refer to the locations of the automata. To eliminate such location references, |
| apply the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This CIF to CIF transformation eliminates all component definitions and |
| instantiations, by actually instantiating the component definitions.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-15">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-12">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-5">Implementation details</h6> |
| <div class="paragraph"> |
| <p>This transformation operates in three phases:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Phase 1: Find the component definitions without any component definitions |
| and/or component instantiations in them.</p> |
| </li> |
| <li> |
| <p>Phase 2: Instantiate the component definitions found in phase 1, by putting |
| the body of the definition in the place of the instantiation, in a component |
| named after the component instantiation. Also removes the component |
| definitions that were just instantiated, and introduces new local algebraic |
| variables for the algebraic parameters.</p> |
| </li> |
| <li> |
| <p>Phase 3: Replace uses of component, event, and location parameters by the |
| actual arguments provided for the instantiation.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group def P(alg int x): |
| invariant x > 0; |
| end |
| |
| p1: P(1); |
| |
| alg int y = 2; |
| p2: P(y);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group p1: |
| alg int x = 1; |
| invariant x > 0; |
| end |
| |
| alg int y = 2; |
| group p2: |
| alg int x = y; |
| invariant x > 0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Absolute references may be needed to express the results of this |
| transformation. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 5; |
| |
| group def X(): |
| invariant x = 5; |
| end |
| |
| group a: |
| x: X(); |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 5; |
| |
| group a: |
| group x: |
| invariant .x = 5; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Note how the invariant in component <code>a.x</code> can not refer to constant <code>x</code> |
| directly, as <code>x</code> refers to component <code>a.x</code> in that context. Therefore, the |
| scope absolute reference <code>.x</code> is used instead.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-5">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-5">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since component definitions are shortcuts for components, eliminating |
| them could result in an increase of the size of the specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-5">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-consts">Eliminate constants</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates constants.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-16">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-13">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-6">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All uses of constants (for instance in guards, invariants, etc), are replaced |
| by their values. The constants themselves are removed. For instance, the |
| following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 1; |
| const int z = y; |
| const int y = x + 1; |
| invariant x + y + z > 0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">invariant 1 + 2 + 2 > 0;</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-6">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-6">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since constants are shortcuts for values, eliminating them could result in an |
| increase of the size of the specification. Constants may be defined in terms of |
| other constants. Therefore, in the worst case, the increase is exponential.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-6">Optimality</h6> |
| <div class="paragraph"> |
| <p>For an assignment <code>x := 1 + y</code>, where <code>y</code> is a constant that is eliminated, |
| and where <code>y</code> has value <code>5</code>, the resulting assignment is <code>x := 1 + 5</code>. |
| The result is not simplified any further. To further simplify the result, apply |
| additional CIF to CIF transformations, such as |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-enums">Eliminate enumerations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates enumerations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also: <a href="#tools-cif2cif-chapter-merge-enums">Merge enumerations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-17">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-14">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>To increase the subset of specifications that can be transformed, apply |
| the following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order) prior to using this transformation:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-7">Implementation details</h6> |
| <div class="paragraph"> |
| <p>Enumerations, which are used as types, are replaced by integer types, with |
| range <code>[0 .. n-1]</code>, where <code>n</code> is the number of literals of the enumeration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Enumeration literals, which are used as values, are replaced by integer values. |
| If the used enumeration literal is the <code>n</code><sup>th</sup> literal in the corresponding |
| enumeration (declaration), then the integer value is <code>n - 1</code>. That is, the |
| integer value is the 0-based index of the enumeration literal into the literals |
| of the enumeration declaration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All enumeration declarations are removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group x: |
| enum EX = A, B; |
| |
| const EX x = A; |
| end |
| |
| group y: |
| enum EY = B, A; |
| |
| const EY y = A; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group x: |
| const int[0..1] x = 0; |
| end |
| |
| group y: |
| const int[0..1] y = 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-7">Renaming</h6> |
| <div class="paragraph"> |
| <p>This transformation itself does not perform any renaming.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If enumeration literals are renamed, this may influence value equality for |
| <em>compatible</em> enumerations (enumerations with the same number of literals, |
| with the same names, in the same order). Therefore, either apply this |
| transformation before applying other transformations that perform renaming on |
| enumeration literals (such as the <a href="#tools-cif2cif-chapter-groups">Eliminate groups</a> CIF to CIF |
| transformation), or otherwise ensure that renaming does not result in an |
| invalid specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-7">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Integer types and integer values are not larger than enumerations and their |
| literals. Therefore, this transformation does not increase the size of the |
| specification. In fact, it may even be smaller.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-7">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-equations">Eliminate equations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates equations for algebraic variables |
| and derivatives of continuous variables. Note that it does not eliminate the |
| variables themselves.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also: <a href="#tools-cif2cif-chapter-elim-alg-vars">Eliminate algebraic variables</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-18">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| <li> |
| <p>Automaton <code>self</code> references are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-15">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-8">Implementation details</h6> |
| <div class="paragraph"> |
| <p>For algebraic variables with a single equation in a component or automaton, |
| the value of the variable (the right hand side of the equation) is moved to |
| the declaration of the algebraic variable. For algebraic variables with |
| equations specified in the locations of an automaton, an 'if' expression is |
| created. This 'if' expression uses the locations of the automaton as guards, |
| and the right hand sides of the equations as values for each of the |
| alternatives. The last alternative is an 'else', and thus has no guard. The |
| single right hand side, or the 'if' expression, is put directly in the |
| declaration of the algebraic variable. If the automaton has only one location, |
| generation of the 'if' expression is suppressed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The derivatives of continuous variables are transformed in a similar way. The |
| derivative ends up in the declaration of the continuous variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All equations are removed from components (including automata) and locations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg bool b1 = true; |
| cont x; |
| equation x' = 1.0; |
| |
| automaton p: |
| alg int a; |
| location l1: |
| equation a = 1; |
| location l2: |
| equation a = 2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg bool b1 = true; |
| cont x der 1.0; |
| |
| automaton p: |
| alg int a = if l1: 1 |
| else 2 |
| end; |
| location l1; |
| location l2; |
| end</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-8">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-8">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The right hand sides of the equations are simply moved. This does not influence |
| the size of the specification. For equations specified in the locations of an |
| automaton, an 'if' expression is created. This increases the size of the |
| specification. The increase however, is linear in the number of equations.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-8">Optimality</h6> |
| <div class="paragraph"> |
| <p>This transformation introduces 'if' expressions for algebraic variables and |
| derivatives of continuous variables that have an equation per location of an |
| automaton, for automata with at least two locations. The guards of such 'if' |
| expressions refer to the locations of the automata. To eliminate such location |
| references, apply the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF |
| transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-groups">Eliminate groups</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation flattens the component structure of a |
| specification, by eliminating all groups. That is, after this transformation, |
| all automata will be at the top level, directly in the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-19">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Furthermore, this transformation does not guarantee the correct result for |
| specification with enumerations. See also the |
| <a href="#tools-cif2cif-elim-groups-renaming">Renaming</a> section below.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-16">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>To increase the subset of specifications that can be transformed, apply |
| the following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order) prior to using this transformation:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| automatically applied as preprocessing (in the given order), to increase the |
| subset of CIF specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-svg-file-into-decls">Push SVG file declarations into other CIF/SVG declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-print-file-into-decls">Push print file declarations into print declarations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-9">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All declarations, invariants, initialization predicates, marker predicates, and |
| equations from the groups are lifted to the top level of the specification. |
| The automata are lifted to the top level of the specification as well. |
| Subsequently, the groups are removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In order to be able to track the origin of automata and declarations, they are |
| named after their absolute names. For a group <code>x</code>, with a group |
| <code>y</code>, with a constant <code>z</code>, the absolute name of the constant is <code>x.y.z</code>. |
| The constant is lifted to the top level of the specification, and named |
| <code>x_y_z</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, this specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group a: |
| const int x = 5; |
| invariant x > 4; |
| end |
| |
| group p: |
| automaton q: |
| event e; |
| location; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int a_x = 5; |
| invariant a_x > 4; |
| |
| automaton p_q: |
| event e; |
| location; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-elim-groups-renaming">Renaming</h6> |
| <div class="paragraph"> |
| <p>Since declarations of the specification are merged with the declarations of the |
| groups and with automata, renaming may be necessary to ensure uniquely |
| named declarations. For instance, for a group <code>x</code>, with a group |
| <code>y</code>, with a constant <code>z</code>, the absolute name of the constant is <code>x.y.z</code>. |
| The constant is lifted to the top level of the specification, and renamed to |
| <code>x_y_z</code>. However, if the specification already contains a declaration of |
| another constant, automaton, etc named <code>x_y_z</code>, then the lifted constant is |
| renamed to <code>x_y_z2</code> instead. If that name is also already in use, it is |
| renamed to <code>x_y_z3</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Whenever renaming takes place, a warning will be printed to the console.</p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-renaming-of-enumeration-literals">Renaming of enumeration literals</h7> |
| <div class="paragraph"> |
| <p>Enumeration literals that are part of lifted enumeration declarations, are not |
| renamed to their absolute names. To understand why this is necessary, consider:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group x: |
| enum E = A, B; |
| end |
| |
| automaton y: |
| enum E = A, B; |
| location: |
| initial; |
| end |
| |
| invariant x.A = y.A;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, group <code>x</code> and automaton <code>y</code> both have an enumeration <code>E</code> with |
| enumeration literals <code>A</code> and <code>B</code>. The invariant of the specification |
| compares the literals of the two different enumerations. This is allowed, since |
| the enumerations are <em>compatible</em> (they have the same enumeration literals, |
| with the same names, in the same order). If we were to rename the enumeration |
| literals to absolute names as we lift them to the top level of the |
| specification, the result would be:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum x_E = x_A, x_B; |
| |
| automaton y: |
| enum E = A, B; |
| location: |
| initial; |
| end |
| |
| invariant x_A = y.A;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Which would no longer be a valid specification, as enumerations <code>x_E</code> and |
| <code>y.E</code> are no longer compatible (they have enumeration literals with different |
| names). Since we leave the names of the enumeration literals as they are, the |
| result of the transformation is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum x_E = A, B; |
| |
| automaton y: |
| enum E = A, B; |
| location: |
| initial; |
| end |
| |
| invariant A = y.A;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>which is still a correct specification, and has the same meaning as the |
| original specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Now assume the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group x: |
| enum E = A, B; |
| end |
| |
| group y: |
| enum E = A, B; |
| end |
| |
| invariant x.A = y.A;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the two enumerations are both in groups. If we lift them, we have |
| two enumerations, with the same literals, which is not a valid CIF |
| specification. As such, renaming can not be avoided, and the result of the |
| transformation will be:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum x_E = A, B; |
| enum y_E = A2, B2; |
| |
| invariant A = A2;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This result is an invalid CIF specification. Whenever an enumeration literal |
| is renamed, a warning is printed to the console, informing of the possibility |
| that the resulting specification is invalid. As such, it is highly recommended |
| to avoid such situations, and eliminate the enumerations prior to the |
| elimination of the groups.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-9">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The groups are removed. Other objects are lifted, which essentially means |
| they are moved. The size of the specification does not increase.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-9">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-if-updates">Eliminate <code>if</code> updates</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates 'if' updates on edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-20">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Multi-assignments and partial variable assignments are not supported. That |
| is, the left hand sides of the assignments on edges (the addressables) must |
| be single variables without projections.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-17">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing, to increase the subset of CIF specifications that can be |
| transformed, is currently performed by this CIF to CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-elim-if-updates-impl">Implementation details</h6> |
| <div class="paragraph"> |
| <p>This transformation ensures that each variable that is assigned, gets |
| a single explicit assignment. Simply put, the 'if' update structure is |
| replicated by an 'if' expression. For instance, the following edge updates:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">if g: |
| if g2: |
| x := 5 |
| else |
| y := 6 |
| end |
| end, |
| z := 7</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>are transformed to the following edge updates:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">x := if g: |
| if g2: |
| 5 |
| else |
| x |
| end |
| else |
| x |
| end, |
| y := if g: |
| if g2: |
| y |
| else |
| 6 |
| end |
| else |
| y |
| end, |
| z := 7</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Observe how variables <code>x</code> and <code>y</code> are assigned inside two <code>if</code> updates. |
| These <code>if</code> updates are replicated by two <code>if</code> expressions.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since for <code>if</code> expressions the <code>else</code> part is not optional, dummy |
| <code>x := x</code> assignments are sometimes performed in cases where the original |
| specification would not have assigned variable <code>x</code> at all. That is, variables |
| may be assigned their old values, resulting in superfluous assignments.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-9">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-10">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The 'if' structure may be replicated for multiple variables, which may result |
| in an increase of the specification size. The increase amount is influenced |
| by the size of the guard expressions, and the number of levels of nesting 'if' |
| updates.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-10">Optimality</h6> |
| <div class="paragraph"> |
| <p>The superfluous assignments (see the <a href="#tools-cif2cif-elim-if-updates-impl">Implementation details</a> |
| section above), are obviously not optimal. The language however requires them.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation eliminates the use of locations in expressions |
| (such as guards, invariants, and equations), by introducing location pointer |
| variables for automata, and using them instead.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-21">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-18">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-10">Implementation details</h6> |
| <div class="paragraph"> |
| <p>For each automaton for which a location is used (referred to) in an expression |
| (such as a guard, invariant, or equation), a location pointer variable is |
| introduced, with as value the current location of the automaton. The values |
| for such a new variables are part of a newly created enumeration that has a |
| value (an enumeration literal) for each location of the automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To initialize the new location pointer variable, the variable itself is |
| initialized to <code>any</code> (meaning any value in its domain), and initialization |
| predicates are added to all locations that could potentially be initial |
| locations. For automata with exactly one initial state, the initial value |
| of the location pointer variable is set directly, instead of using |
| initialization predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All edges in the automaton that change the current location of that automaton, |
| get an additional assignment to update the location pointer variable.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All uses of the locations of the automaton in expressions (that is, all |
| location reference expressions) are changed to equality binary expressions for |
| the location pointer variable and the enumeration literal corresponding to the |
| location.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton x: |
| event e; |
| alg bool a = l1; |
| |
| location l1: |
| initial; |
| edge e goto l2; |
| |
| location l2: |
| edge e; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton x: |
| event e; |
| alg bool a = LP_x = LOC_l1; |
| disc LOCS_x LP_x = LOC_l1; |
| enum LOCS_x = LOC_l1, LOC_l2; |
| |
| location l1: |
| initial; |
| edge e do LP_x := LOC_l2 goto l2; |
| |
| location l2: |
| edge e; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Location pointer variable <code>LP_x</code> is added. It is initialized directly in the |
| declaration, since there is exactly one initial location in this automaton. |
| Enumeration <code>LOCS_x</code> is created to represent the possible values of the |
| location pointer variable. Enumerations literals <code>LOC_l1</code> and <code>LOC_l2</code> |
| represent locations <code>l1</code> and <code>l2</code>, respectively.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The edge from location <code>l1</code> to location <code>l2</code> is extended with an update |
| to the location pointer. The self loop in location <code>l2</code> is not extended, as |
| the location does not change.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-10">Renaming</h6> |
| <div class="paragraph"> |
| <p>If the names of the location pointer variables that are introduced, conflict |
| with already existing declarations, they are renamed. For instance, if <code>LP_x</code> |
| is already in use, <code>LP_x2</code>, <code>LP_x3</code>, etc, are used instead. Similarly, |
| renaming is performed for enumerations, and enumeration literals that conflict |
| with already existing declarations. If renaming takes place, a warning is |
| printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-11">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The number of added location pointer variables is linear in the number of |
| automata. The number of added initialization predicates for the location |
| pointer variables is linear in the number of possible initial locations. The |
| number of added enumerations is linear in the number of automata. The number of |
| added enumeration literals is linear in the number of locations. The number of |
| added updates is linear in the number of edges. The number of added equality |
| binary expressions is linear in the number of location references.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-11">Optimality</h6> |
| <div class="paragraph"> |
| <p>This transformation introduces enumerations for the possible values of the |
| location pointer variables. To eliminate the enumerations, apply the |
| <a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a> CIF to CIF transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-monitors">Eliminate monitors</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates monitor events.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-22">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-19">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-11">Implementation details</h6> |
| <div class="paragraph"> |
| <p>For each monitor event in an automaton, additional self loops are added as |
| needed, to make sure the automaton doesn’t disable the monitor event. |
| Furthermore, all monitors are removed from all automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The self loop edges created by this transformation have no communication |
| (no <code>!...</code>, no <code>?...</code>), no urgency (no <code>now</code>), and no updates |
| (no <code>do ...</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, for the following locations and edges, for monitor event <code>e</code>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">location l1: |
| edge e goto l2; |
| edge f when x = 2 goto l3; |
| |
| location l2: |
| edge e when x = 1 goto l3; |
| edge e when x = 2 goto l1; |
| |
| location l3;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>the result after this transformation is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">location l1: |
| edge e goto l2; |
| edge f when x = 2 goto l3; |
| |
| location l2: |
| edge e when x = 1 goto l3; |
| edge e when x = 2 goto l1; |
| edge e when not(x = 1 or x = 2); |
| |
| location l3: |
| edge e;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In location <code>l1</code>, monitor event <code>e</code> is always enabled (no guard implies |
| a <code>true</code> guard), and thus no additional self loop is needed. In location |
| <code>l2</code>, event <code>e</code> is only enabled if <code>x</code> has either value <code>1</code> or value |
| <code>2</code>. A self loop is added for all other cases, to ensure the event is always |
| enabled. In location <code>l3</code>, the event is never enabled (no edges, which |
| essentially means guard <code>false</code>). A self loop is added, to ensure the event |
| is always enabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Event <code>f</code> is not a monitor event, and is thus not affected by this |
| transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-11">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-12">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since self loop edges may be added by this transformation, the size of the |
| specification may increase.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-12">Optimality</h6> |
| <div class="paragraph"> |
| <p>For an edge with guard <code>x = 1</code>, a self loop with guard <code>not (x = 1)</code> may |
| be generated by this transformation. The guard could be simplified to |
| <code>x != 1</code>. However, this transformation does not simplify guards. To further |
| simplify the result, apply additional CIF to CIF transformations, such as |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation replaces implicit automaton <code>self</code> references |
| by explicit automaton references.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-23">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-20">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-12">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All implicit automaton <code>self</code> references are replaced by explicit automaton |
| references. For instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| alg string x = <string>self; |
| |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This is transformed to the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton a: |
| alg string x = <string>a; |
| |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-12">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-13">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since both references are single expression nodes, this transformation does not |
| increase the size of the specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-13">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-state-event-excl-invs">Eliminate state/event exclusion invariants</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates state/event exclusion invariants. It |
| replaces them with automata with self loops.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-24">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-21">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-13">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All state/event exclusion invariants are removed from the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>They are replaced with automata with self loops. Per component, the state/event |
| exclusion invariants of the component (the top level scope of the |
| specification, groups, automata), as well as those of its locations (only for |
| automata), are partitioned per |
| <a href="#lang-tut-extensions-synthesis-invkind">supervisory kind</a>. Per such |
| partition, an automaton is created.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The automaton is put along side the component (for groups and automata), as |
| sibling. For invariants in the top level scope of the specification, the new |
| automaton is put in the top level scope of the specification. The new automaton |
| gets the same name as the component that contained the invariants as prefix, |
| with some postfixes. For invariants at the top level scope of the |
| specification, an empty prefix is used. The first postfix is indicates the |
| supervisory kind of the invariants of the partition: <code>Plant</code>, |
| <code>Requirement</code>, <code>Supervisor</code>, or empty for regular/kindless invariants. |
| The second postfix is <code>StateEvtExcls</code>. So, for an automaton <code>Abc</code> with |
| some plant invariants, an automaton <code>AbcPlantStateEvtExcls</code> is created. The |
| name may conflict with existing automata or other declarations, in which case |
| it is <a href="#tools-cif2cif-elim-state-event-excl-invs-renaming">renamed</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The automata that are created inherit the supervisory kind of the state/event |
| exclusion invariants in the partition for which the automaton is created. The |
| automata have a single nameless location, that is both initial and marked.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For each state/event exclusion invariant in the partition, and self loop edge |
| is created per event. The condition predicates of the invariants are used as |
| guard, possible after some manipulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For state/event exclusion invariants of the locations of automata, the |
| condition predicate is made conditional on the location. However, this is only |
| done for automata with at least two locations, as conditioning on an always |
| active location is of little use. For a location <code>loc</code>, and a state/event |
| exclusion invariant <code>invariant evt needs x = 1</code>, predicate <code>x = 1</code> is |
| changed to <code>loc => x = 1</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For state/event exclusion invariants that indicate when an event is to be |
| disallowed/disabled, the condition predicate is inverted. The inversion is |
| performed after the condition predicate is made condition on the location, if |
| applicable. For instance, for a state/event exclusion invariant |
| <code>invariant x != 1 disables evt</code> in a location <code>loc</code>, the condition |
| predicate <code>x != 1</code> is first made conditional on the location. This results in |
| <code>loc => x != 1</code>. The condition predicate is then inverted to |
| <code>not(loc => x != 1)</code>, which is then used as guard.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The alphabets of the automata are left implicit.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Consider the following example CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton aut: |
| controllable e1, e2, e3; |
| disc int[0..10] x; |
| |
| requirement invariant e1 needs x < 10; |
| requirement invariant x = 0 disables {e1, e2}; |
| |
| location: |
| initial; |
| |
| requirement invariant x = 0 disables e3; |
| |
| edge e1 do x := x + 1; |
| edge e2 do x := x - 1; |
| edge e3 do x := 0; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>It is transformed to the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton aut: |
| controllable e1, e2, e3; |
| disc int[0..10] x; |
| |
| location: |
| initial; |
| |
| edge e1 do x := x + 1; |
| edge e2 do x := x - 1; |
| edge e3 do x := 0; |
| end |
| |
| requirement automaton autRequirementStateEvtExcls: |
| location: |
| initial; |
| marked; |
| |
| edge aut.e1 when aut.x < 10, not(aut.x = 0); |
| edge aut.e2 when not(aut.x = 0); |
| edge aut.e3 when not(aut.x = 0); |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-elim-state-event-excl-invs-renaming">Renaming</h6> |
| <div class="paragraph"> |
| <p>New automata are created. If the desired name for an automaton is already in |
| use for some other automaton or declaration, the new automaton is given a |
| different name. For instance, if an automaton is to be named |
| <code>ControllerStateEvtExcls</code> and that name is already in use, it will be named |
| <code>ControllerStateEvtExcls2</code>. If that name is also already in use, it will be |
| named <code>ControllerStateEvtExcls3</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-14">Size considerations</h6> |
| <div class="paragraph"> |
| <p>The constant amount of additional objects are created (e.g. an automaton, a |
| location, a <code>true</code> initialization predicate, etc). At most one automaton is |
| created per state/event exclusion invariant. As such, the size increase is |
| linear in the number of state/event exclusion invariants.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-14">Optimality</h6> |
| <div class="paragraph"> |
| <p>For state/event exclusion invariants that are defined in locations of automata |
| with more than one location, this transformation makes their predicates |
| conditional on those locations. To eliminate such location references, apply |
| the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation generate boolean implication and inversion predicates. |
| These are not simplified. To simply them, apply the |
| the <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> CIF to CIF transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-tau-event">Eliminate <code>tau</code> event</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates the <code>tau</code> event.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-25">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-22">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-14">Implementation details</h6> |
| <div class="paragraph"> |
| <p>This transformation introduces new events for the <code>tau</code> event, one per |
| automaton where a <code>tau</code> event is used. The new events are named <code>tau_</code> (if |
| that name is not already in use).</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the alphabet is explicit specified, it is extended as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The new events are neither controllable nor uncontrollable, and don’t have a |
| data type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| |
| location l1: |
| initial; |
| edge when true goto l2; |
| |
| location l2: |
| edge e, tau goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| event tau_; |
| |
| location l1: |
| initial; |
| edge tau_ when true goto l2; |
| |
| location l2: |
| edge e, tau_ goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-13">Renaming</h6> |
| <div class="paragraph"> |
| <p>The newly introduced <code>tau_</code> events are renamed to <code>tau_2</code>, <code>tau_3</code>, etc, |
| if they conflict with other declarations with the same name, that already |
| exist in the automata. If renaming is needed, a warning is printed to the |
| console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-15">Size considerations</h6> |
| <div class="paragraph"> |
| <p>New events may be added, the alphabet may be extended, and an explicit event |
| may be added to edges. Therefore, the size of the specification may increase.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-15">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-tuple-field-projs">Eliminate tuple field projections</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates tuple field projections by replacing |
| them with tuple index projections.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-26">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-23">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-15">Implementation details</h6> |
| <div class="paragraph"> |
| <p>Obtaining the value of a field of a tuple is called tuple projection. |
| There are two ways to project a tuple. That is, there are two ways to indicate |
| from which field to obtain the value. The first way is to use the name of the |
| field, the second way is to use the 0-based index of the field into the fields |
| of the tuple’s type. For instance:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const tuple(int a; real b) t = (1, 2.0); |
| const int x = t[a]; |
| const int y = t[0];</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, both constants <code>x</code> and <code>y</code> have value <code>1</code>, obtained from field |
| <code>a</code> of the tuple value of constant <code>t</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation replaces tuple field projections (using the name of the |
| field), by tuple index projections (using the 0-based index of the field). For |
| instance, for the example above, the result of this transformation is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const tuple(int a; real b) t = (1, 2.0); |
| const int x = t[0]; |
| const int y = t[0];</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-14">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-16">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since both field references and integer values are single expression nodes, |
| this transformation does not increase the size of the specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-16">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-elim-type-decls">Eliminate type declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation eliminates type declarations.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-27">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-24">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-16">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All uses of type declarations (in types of variables, types of other type |
| declarations, etc), are replaced by the types of those type declarations. The |
| type declarations themselves are removed. For instance, the following |
| specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">type t = int; |
| type u = v; |
| type v = tuple(t a, b); |
| |
| const t x = 1; |
| const u y = (2, 3); |
| const v z = (4, 5);</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 1; |
| const tuple(int a, b) y = (2, 3); |
| const tuple(int a, b) z = (4, 5);</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-15">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-17">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since type declarations are shortcuts for types, eliminating them could result |
| in an increase of the size of the specification. Type declarations may be |
| defined in terms of other type declarations. Therefore, in the worst case, the |
| increase is exponential.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-17">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-lift-events">Lift events</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation lifts event declarations to the top level of the |
| specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-28">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| <li> |
| <p>Groups are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-25">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-groups">Eliminate groups</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-17">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All events declared in the automata, are lifted to the top level of the |
| specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In order to be able to track the origin of the events, they are named after |
| their absolute names. For a group <code>x</code>, with a group <code>y</code>, with an |
| event <code>e</code>, the absolute name of the event is <code>x.y.e</code>. The event is lifted |
| to the top level of the specification, and named <code>x_y_e</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, this specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| |
| automaton a: |
| event e; |
| location; |
| end |
| |
| group b: |
| automaton c: |
| event e; |
| location; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| event a_e; |
| event b_c_e; |
| |
| automaton a: |
| location; |
| end |
| |
| group b: |
| automaton c: |
| location; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-16">Renaming</h6> |
| <div class="paragraph"> |
| <p>Since events of the automata are merged with the declarations of the |
| specification, renaming may be necessary to ensure uniquely named declarations. |
| For instance, for a group <code>x</code>, with a group <code>y</code>, with an event |
| <code>e</code>, the absolute name of the event is <code>x.y.e</code>. The event is lifted to the |
| top level of the specification, and renamed to <code>x_y_e</code>. However, if the |
| specification already contains a declaration of a constant, automaton, other |
| event, etc, named <code>x_y_e</code>, then the lifted event is renamed to <code>x_y_e2</code> |
| instead. If that name is also already in use, it is renamed to <code>x_y_e3</code>, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Whenever renaming takes place, a warning is be printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-18">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Events are lifted, which essentially means they are moved. The size of the |
| specification does not increase.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-18">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-linearize-merge">Linearize (merge)</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation performs process-algebraic linearization, |
| thereby eliminating parallel composition and event synchronization.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-29">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Specifications without automata are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-26">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-pos-info">Remove position information</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-groups">Eliminate groups</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-switches-to-ifs">Convert <code>switch</code> expressions to <code>if</code> expressions</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-equations">Eliminate equations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-aut-casts">Eliminate automata to string casts</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-18">Implementation details</h6> |
| <div class="paragraph"> |
| <p>A location pointer variable is introduced for each original automaton, and the |
| use of locations in expressions is eliminated. This is mostly similar to what |
| the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF transformation does, |
| except that for instance location pointer variables are added for all automata. |
| For nameless locations, name <code>X</code> is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One new automaton, named <code>M</code>, is created. If all original automata have |
| the same supervisory kind, the new automaton gets this kind as well. Otherwise, |
| it gets no supervisory kind. The alphabet of this new automaton is the union of |
| alphabets of the original automata, including the events that are used to |
| send or receive in any of the automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All declarations from the original automata are moved to the new automaton. |
| They are renamed based on their absolute names. That is, for an automaton <code>a</code> |
| with a constant <code>c</code>, the absolute name of the constant is <code>a.c</code> and the |
| moved constant will be named <code>a_c</code>. Enumeration literals are not given |
| absolute names, and keep their original names |
| <a href="#tools-cif2cif-linearize-merge-renaming">if possible</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One location, named <code>L</code>, is added. This location is both initial and marked. |
| All initialization and marker predicates from all the original automata |
| (including ones from locations) are merged together. They are put in the new |
| automaton, and restrict the initialization and marker predicates of location |
| <code>L</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The invariants of the original automata (including ones from locations) are |
| merged together in a similar way as the initialization and marker predicates. |
| The supervisory kinds of the invariants are made explicit, to ensure that the |
| original supervisory kinds inherited from automata are preserved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the <code>tau</code> event, a self loop is created per original <code>tau</code> edge. For |
| all other events, the edges are merged, resulting in a single self loop for |
| each non-<code>tau</code> event. By creating single edges per non-<code>tau</code> event, |
| <a href="#tools-cif2cif-linearize-merge-nondet">non-deterministic choice</a> may be |
| eliminated, ensuring that the model size of the resulting specification is |
| near-linear <a href="#tools-cif2cif-linearize-merge-size">compared to</a> the model |
| size of the original specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Monitors are taken into account when merging the guards of the edges, resulting |
| in simpler guard predicates. Communication is eliminated altogether, and events |
| no longer have data types after linearization. For edges with receives, the |
| 'received value' is replaced (in the updates) by the 'send value'.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| |
| plant automaton p: |
| disc int x = 1; |
| |
| location l1: |
| initial; |
| edge e when x = 1 do x := 2 goto l2; |
| |
| location l2: |
| edge e when x = 2 do x := 1 goto l1; |
| end |
| |
| plant automaton q: |
| location l1: |
| initial; |
| edge tau goto l2; |
| |
| location l2: |
| edge e goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| enum E = l1, l2; |
| |
| plant automaton M: |
| alphabet e; |
| |
| disc int p_x = 1; |
| disc E p = l1; |
| disc E q = l1; |
| |
| initial p = l1 and true or p = l2 and false, |
| q = l1 and true or q = l2 and false; |
| |
| marked p = l1 and false or p = l2 and false, |
| q = l1 and false or q = l2 and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge e when (p = l1 and p_x = 1 or p = l2 and p_x = 2) and |
| (q = l1 and false or q = l2 and true) |
| do if p = l1 and p_x = 1: p_x := 2, p := l2 |
| elif p = l2 and p_x = 2: p_x := 1, p := l1 |
| end, |
| q := l1; |
| edge tau when q = l1 do q := l2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We see that an enumeration <code>E</code> is added, with literals for all the locations |
| of the original automata. We also see that plant automata <code>p</code> and <code>q</code> are |
| linearized to plant automaton <code>M</code>. Two location pointers, <code>p</code> and <code>q</code>, |
| named after the original automata, are added. The variables are moved. The |
| initialization and marker predicates are linearized. We have one location |
| <code>L</code>, which is initial and marked. For event <code>e</code>, the guards and updates are |
| linearized into a single self loop. Location pointer updates are incorporated |
| as well. For event <code>tau</code>, the single original edge is simply included as a |
| self loop.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-cif2cif-linearize-merge-nondet">Non-determinism</h7> |
| <div class="paragraph"> |
| <p>If the original automata have non-determinism, this choice is eliminated as |
| part of this transformation. Non-determinism can be present due to multiple |
| outgoing edges for a single location, for the same event (excluding the |
| <code>tau</code> event), with overlapping guards. Another cause of non-determinism is |
| multiple senders or receivers that are enabled at the same time, for the same |
| channel. In the resulting specification, the first possible transition is |
| always taken, similar to how the simulator chooses, assuming the simulator is |
| configured to always automatically choose the |
| <a href="#tools-cifsim-input-chapter-automatic">first transition</a>. Linearization eliminates some of the |
| non-determinism in this case, essentially choosing a specific trace through |
| the state space. To ensure the same choices are made, events and automata are |
| sorted in the same order for linearization and simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| disc int x = 0; |
| |
| location: |
| edge e when x < 5 do x := x + 1; |
| edge e when x > 3 do x := x - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = X; |
| |
| automaton M: |
| alphabet p_e; |
| |
| event p_e; |
| |
| disc int p_x = 0; |
| disc E p in any; |
| |
| initial p = X and false; |
| marked p = X and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge p_e when p = X and (p_x < 5 or p_x > 3) |
| do if p = X and p_x < 5: p_x := p_x + 1 |
| elif p = X and p_x > 3: p_x := p_x - 1 |
| end; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, we see that the edge for event <code>e</code> with guard <code>x < 5</code> and update |
| <code>x := x + 1</code> is chosen to take precedence over the edge with guard <code>x > 3</code> |
| with update <code>x := x - 1</code>. This choice is based on the original specification, |
| where the edge with guard <code>x < 5</code> is listed before the edge with guard |
| <code>x > 3</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Related to this, are dummy updates, which are added to ensure that the correct |
| updates are taken. For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| disc int x = 0; |
| location: |
| edge e when x >= 3; |
| edge e when x < 3 do x := x + 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = X; |
| |
| automaton M: |
| alphabet p_e; |
| event p_e; |
| |
| disc int p_x = 0; |
| disc E p in any; |
| |
| initial p = X and false; |
| marked p = X and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge p_e when p = X and (p_x >= 3 or p_x < 3) |
| do if p = X and p_x >= 3: p := X |
| elif p = X and p_x < 3: p_x := p_x + 1 |
| end; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, the edge with guard <code>x >= 3</code> takes precedence over the edge with guard |
| <code>x < 3</code>. To ensure that no updates are performed when the edge with guard |
| <code>x >= 3</code> is chosen, a dummy update is added (reassigning the location pointer |
| variable the value it already has). If this update were to be omitted, the |
| update of the other edge would instead be executed, which is undesirable.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-order">Order</h7> |
| <div class="paragraph"> |
| <p>If code generation is performed on a linearized version of the specification, |
| it may be a good idea to ensure the same order is used and the same choices |
| are made, both in the generated code and in simulation. Assuming simulation |
| was performed by always automatically choosing the |
| <a href="#tools-cifsim-input-chapter-automatic">first transition</a>, this should correspond to the output of |
| linearization. The linearized edges are in the same order as the transitions |
| are calculated by the simulator. This is ensured by sorting events and automata |
| in the same order for linearization and simulation. Also, as the |
| <a href="#tools-cif2cif-linearize-merge-nondet">Non-determinism</a> section above explains, if |
| non-determinism is eliminated, it is done in a way that preserves that order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Code should thus be generated in the order of the linearized edges resulting |
| from linearization. Each time the code for an edge is executed, the code should |
| start from the top, to ensure always the first enabled transition is chosen.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-urgency">Urgency</h7> |
| <div class="paragraph"> |
| <p>If the original automata contain urgent locations and/or urgent edges, a |
| discrete boolean variable <code>u</code> is added to the linearized automaton. |
| Initially, it’s value is <code>true</code>, and it must always remain so |
| (<code>plant invariant u;</code>). We add self loops (event <code>tau</code>), with as guard the |
| urgent locations and guards of urgent edges, such that the edge can be taken if |
| the system is in an urgent location, or an urgent edge is enabled (guard wise). |
| However, these edges update <code>u</code> to <code>false</code>, which violates the target |
| location invariant, meaning we can never take these edges in a transition. |
| Since the edge is also urgent, it means that if the edge is enabled guard wise, |
| time may not progress, thus ensuring the urgency behavior of the original |
| urgent locations and edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| |
| location l1: |
| initial; |
| urgent; |
| edge e when true goto l2; |
| |
| location l2: |
| edge e when 1 = 1 now goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = l1, l2; |
| |
| automaton M: |
| alphabet p_e; |
| event p_e; |
| |
| disc E p = l1; |
| disc bool u = true; |
| |
| initial p = l1 and true or p = l2 and false; |
| marked p = l1 and false or p = l2 and false; |
| |
| plant invariant u; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge p_e when p = l1 and true or p = l2 and 1 = 1 |
| do if p = l1 and true: p := l2 |
| elif p = l2 and 1 = 1: p := l1 |
| end; |
| |
| edge when p = l1 or p = l2 and 1 = 1 now do u := false; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>So, if <code>p</code> (the location pointer variable for original automaton <code>p</code>) is |
| equal to <code>l1</code> (the enumeration literal for original location <code>l1</code>), then |
| the guard of the new urgent edge is enabled, and time may not progress. |
| Similarly, if <code>p</code> is equal to <code>l2</code> and the guard <code>1 = 1</code> of the original |
| urgent edge is enabled, the guard of the new urgent edge is enabled, and time |
| may not progress. This correctly reflects the urgency conditions of the |
| original specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To ensure that no additional event transitions are possible, the new urgent |
| edge can never be taken, as it would update <code>u</code> to <code>false</code>, which violates |
| <code>plant invariant u</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-received-values-and-tuple-field-projections">Received values and tuple field projections</h7> |
| <div class="paragraph"> |
| <p>The following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event tuple(int a, b) e; |
| |
| automaton s: |
| location: |
| edge e!(1, 2); |
| end |
| |
| automaton r: |
| disc int x; |
| location: |
| edge e? do x := ?[a]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| enum E = X; |
| |
| automaton M: |
| alphabet e; |
| |
| disc E s in any; |
| disc int r_x; |
| disc E r in any; |
| |
| initial s = X and false, |
| r = X and false; |
| marked s = X and false, |
| r = X and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge e when s = X and true and (r = X and true) do r_x := (1, 2)[0]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Observe how event <code>e</code> no longer has a data type, and the communication (send |
| and receive) have been eliminated. In the assignment <code>x := ?[a]</code>, received |
| value <code>?</code> has been replaced by send value <code>(1, 2)</code>. Since tuple values |
| don’t have field names, the right hand side <code>(1, 2)[a]</code> has been replaced |
| by <code>(1, 2)[0]</code>, using the <a href="#tools-cif2cif-chapter-elim-tuple-field-projs">Eliminate tuple field projections</a> CIF to |
| CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-elimination-of-communication">Elimination of communication</h7> |
| <div class="paragraph"> |
| <p>Since channel communication is completely eliminated, and channels become |
| regular events after this transformation, it is no longer possible to |
| <a href="#tools-chapter-mergecif">merge</a> additional senders/receivers with the linearized |
| specification. If you wish to merge another specification with additional |
| communication partners, first perform the merging, and then the linearization.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-linearize-merge-renaming">Renaming</h6> |
| <div class="paragraph"> |
| <p>Since declarations are moved/merged, and new names are introduced, renaming may |
| be necessary to ensure unique names within a single scope. In order to reduce |
| the amount of renaming for the enumeration literals introduced for the |
| locations of the original automata, all enumerations are merged together into a |
| single enumeration in the specification, with name <code>E</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If renaming is performed, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-linearize-merge-size">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Declarations are moved, so they don’t increase the size of the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The addition of location variables increases the size of the specification, but |
| this is linear in the number of automata and the number of locations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Assignment are added for the updates to the location pointers. The increase is |
| linear in the number of edges. The additional dummy updates that are added are |
| linear in the number of edges as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A single self loop is added for each non-<code>tau</code> event. This does increase the |
| size of the specification. The guards are simply combined using boolean |
| operators, and the increase is therefore linear in the number of guards. |
| Similarly, updates are combined using 'if' updates, and the increase is also |
| linear.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For original edges with multiple events however, the guards and updates are |
| duplicated for each event. The duplication is linear in the number of events |
| on those edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since <code>tau</code> edges are essentially just moved, they don’t increase the size |
| of the specification. That is, their size is linear in the number of original |
| <code>tau</code> edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The initialization and marker predicates, as well as the invariants are moved. |
| They remain linear in size related to the number of original predicates. The |
| predicates for the locations are also made conditional on the values of the |
| location pointer variable. This size increase is linear in the number of |
| original locations. Predicates are combined using boolean operators, leading |
| to a size increase that is linear in the number of original predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a single received value is used multiple times in the updates of a single |
| edge, the send value is duplicated for each of those uses. As such, the size |
| increase is linear in the number of uses of the received value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If multiple senders and multiple receivers (individual send/receive edges, not |
| whole automata) are present for a certain event, then the received value is |
| expanded to all the potential send values, with the conditions under which they |
| are used as send value (using an 'if' expression). As such, the received |
| value are expanded into expressions that are linear in the number of senders. |
| If we have only a single sender or a single receiver, this is linear. If we |
| have multiple of both, this becomes quadratic (number of senders times number |
| of receivers).</p> |
| </div> |
| <div class="paragraph"> |
| <p>For urgency, an additional variable and invariant are added. This is a constant |
| increase in size. A self loop is added as well. This self loop duplicates |
| the guards of urgent edges. It also includes predicates for the urgent |
| locations. The size of this edge is linear in the number of urgent locations, |
| and the guards of the urgent edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the above, it should be clear that while the specification may increase |
| in size, it is mostly linear. Practically, the size of the linearized |
| specification is usually linear compared to the size of the input |
| specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-19">Optimality</h6> |
| <div class="paragraph"> |
| <p>As should be clear from the examples above, this transformation does not try |
| to generate optimized expressions. In fact, often almost all generated |
| expressions can easily be simplified. To further simplify the result, apply |
| additional CIF to CIF transformations, such as |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Currently, no effort is made by this transformation to reduce for instance the |
| number of dummy assignments, or the number of replacements of tuple field |
| projections by tuple index projections.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-linearize-product">Linearize (product)</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation performs process-algebraic linearization, |
| thereby eliminating parallel composition and event synchronization.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-30">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Specifications without automata are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-27">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-pos-info">Remove position information</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-groups">Eliminate groups</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-switches-to-ifs">Convert <code>switch</code> expressions to <code>if</code> expressions</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-equations">Eliminate equations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-aut-casts">Eliminate automata to string casts</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-19">Implementation details</h6> |
| <div class="paragraph"> |
| <p>A location pointer variable is introduced for each original automaton, and the |
| use of locations in expressions is eliminated. This is mostly similar to what |
| the <a href="#tools-cif2cif-chapter-elim-locs-in-exprs">Eliminate the use of locations in expressions</a> CIF to CIF transformation does, |
| except that for instance location pointer variables are added for all automata. |
| For nameless locations, name <code>X</code> is used.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One new automaton, named <code>M</code>, is created. If all original automata have |
| the same supervisory kind, the new automaton gets this kind as well. Otherwise, |
| it gets no supervisory kind. The alphabet of this new automaton is the union of |
| alphabets of the original automata, including the events that are used to |
| send or receive in any of the automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All declarations from the original automata are moved to the new automaton. |
| They are renamed based on their absolute names. That is, for an automaton <code>a</code> |
| with a constant <code>c</code>, the absolute name of the constant is <code>a.c</code> and the |
| moved constant will be named <code>a_c</code>. Enumeration literals are not given |
| absolute names, and keep their original names |
| <a href="#tools-cif2cif-linearize-product-renaming">if possible</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>One location, named <code>L</code>, is added. This location is both initial and marked. |
| All initialization and marker predicates from all the original automata |
| (including ones from locations) are merged together. They are put in the new |
| automaton, and restrict the initialization and marker predicates of location |
| <code>L</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The invariants of the original automata (including ones from locations) are |
| merged together in a similar way as the initialization and marker predicates. |
| The supervisory kinds of the invariants are made explicit, to ensure that the |
| original supervisory kinds inherited from automata are preserved.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For the <code>tau</code> event, a self loop is created per original <code>tau</code> edge. For |
| all other events, the |
| <a href="http://en.wikipedia.org/wiki/Cartesian_product">Cartesian product</a> |
| of all |
| edges is created, combining the edges in all possible combinations. This |
| results in self loops for all non-<code>tau</code> events, where the combination of all |
| self loops maintains all non-deterministic choices of the original |
| specification. Worst case, the model size of the resulting specification |
| compared to the model size of the original specification |
| <a href="#tools-cif2cif-linearize-product-size">could blow up</a> exponentially.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Monitors are taken into account when merging the guards of the edges, resulting |
| in simpler guard predicates. Communication is eliminated altogether, and events |
| no longer have data types after linearization. For edges with receives, the |
| 'received value' is replaced (in the updates) by the 'send value'.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| |
| plant automaton p: |
| disc int x = 1; |
| |
| location l1: |
| initial; |
| edge e when x = 1 do x := 2 goto l2; |
| |
| location l2: |
| edge e when x = 2 do x := 1 goto l1; |
| end |
| |
| plant automaton q: |
| location l1: |
| initial; |
| edge tau goto l2; |
| |
| location l2: |
| edge e goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| enum E = l1, l2; |
| |
| plant automaton M: |
| alphabet e; |
| |
| disc int p_x = 1; |
| disc E p = l1; |
| disc E q = l1; |
| |
| initial p = l1 and true or p = l2 and false, |
| q = l1 and true or q = l2 and false; |
| |
| marked p = l1 and false or p = l2 and false, |
| q = l1 and false or q = l2 and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge e when p = l1 and p_x = 1 and q = l2 |
| do p_x := 2, p := l2, q := l1; |
| edge e when p = l2 and p_x = 2 and q = l2 |
| do p_x := 1, p := l1, q := l1; |
| edge tau when q = l1 do q := l2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>We see that an enumeration <code>E</code> is added, with literals for all the locations |
| of the original automata. We also see that plant automata <code>p</code> and <code>q</code> are |
| linearized to plant automaton <code>M</code>. Two location pointers, <code>p</code> and <code>q</code>, |
| named after the original automata, are added. The variables are moved. The |
| initialization and marker predicates are linearized. We have one location |
| <code>L</code>, which is initial and marked. For event <code>e</code>, two self loop edges are |
| added, as automaton <code>p</code> has two edges for <code>e</code> and automaton <code>q</code> has one |
| edge for <code>e</code> and <code>2 * 1</code> is <code>2</code>. For the self loop edges, the guards and |
| updates are combined. Location pointer updates are incorporated as well. For |
| event <code>tau</code>, the single original edge is simply included as a self loop.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-non-determinism">Non-determinism</h7> |
| <div class="paragraph"> |
| <p>If the original automata have non-determinism, this choice is maintained as |
| part of this transformation. Non-determinism can be present due to multiple |
| outgoing edges for a single location, for the same event (excluding the |
| <code>tau</code> event), with overlapping guards. Another cause of non-determinism is |
| multiple senders or receivers that are enabled at the same time, for the same |
| channel. In the resulting specification, all possible combinations are |
| included as self loops. For a specification with 4 sender automata with two |
| send edges each (8 send edges in total) and 5 receiver automata with two |
| receive edges each (10 receive edges in total) for event <code>e</code>, and also 6 |
| automata with two edges each that synchronize over that event (12 |
| synchronization edges in total), the number of possible combinations for |
| communication with synchronization is <code>8 * 10 * 12</code>, which is <code>960</code> |
| possible combinations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| |
| automaton p: |
| disc int x = 0; |
| |
| location: |
| edge e when x < 5 do x := x + 1; |
| edge e when x > 3 do x := x - 1; |
| end |
| |
| automaton q: |
| disc int y = 0; |
| |
| location: |
| edge e when y < 5 do y := y + 1; |
| edge e when y > 3 do y := y - 1; |
| edge e when y = 4 do y := y - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| |
| enum E = X; |
| |
| automaton M: |
| alphabet e; |
| |
| disc int p_x = 0; |
| disc E p in any; |
| disc int q_y = 0; |
| disc E q in any; |
| |
| initial p = X and false, |
| q = X and false; |
| |
| marked p = X and false, |
| q = X and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge e when p = X and p_x < 5 and q = X and q_y < 5 |
| do p_x := p_x + 1, q_y := q_y + 1; |
| edge e when p = X and p_x < 5 and q = X and q_y > 3 |
| do p_x := p_x + 1, q_y := q_y - 1; |
| edge e when p = X and p_x < 5 and q = X and q_y = 4 |
| do p_x := p_x + 1, q_y := q_y - 1; |
| edge e when p = X and p_x > 3 and q = X and q_y < 5 |
| do p_x := p_x - 1, q_y := q_y + 1; |
| edge e when p = X and p_x > 3 and q = X and q_y > 3 |
| do p_x := p_x - 1, q_y := q_y - 1; |
| edge e when p = X and p_x > 3 and q = X and q_y = 4 |
| do p_x := p_x - 1, q_y := q_y - 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Here, we see that for event <code>e</code>, automaton <code>p</code> has two edges and automaton |
| <code>q</code> has three edges. The linearization result has six edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-order-2">Order</h7> |
| <div class="paragraph"> |
| <p>If code generation is performed on a linearized version of the specification, |
| it may be a good idea to ensure the same order is used and the same choices |
| are made, both in the generated code and in simulation. Assuming simulation |
| was performed by always automatically choosing the |
| <a href="#tools-cifsim-input-chapter-automatic">first transition</a>, this should correspond to the output of |
| linearization. The linearized edges are in the same order as the transitions |
| are calculated by the simulator. This is ensured by sorting events and automata |
| in the same order for linearization and simulation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Code should thus be generated in the order of the linearized edges resulting |
| from linearization. Each time the code for an edge is executed, the code should |
| start from the top, to ensure always the first enabled transition is chosen.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-urgency-2">Urgency</h7> |
| <div class="paragraph"> |
| <p>If the original automata contain urgent locations and/or urgent edges, a |
| discrete boolean variable <code>u</code> is added to the linearized automaton. |
| Initially, it’s value is <code>true</code>, and it must always remain so |
| (<code>plant invariant u;</code>). We add self loops (event <code>tau</code>), with as guard the |
| urgent locations and guards of urgent edges, such that the edge can be taken if |
| the system is in an urgent location, or an urgent edge is enabled (guard wise). |
| However, these edges update <code>u</code> to <code>false</code>, which violates the target |
| location invariant, meaning we can never take these edges in a transition. |
| Since the edge is also urgent, it means that if the edge is enabled guard wise, |
| time may not progress, thus ensuring the urgency behavior of the original |
| urgent locations and edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">automaton p: |
| event e; |
| |
| location l1: |
| initial; |
| urgent; |
| edge e when true goto l2; |
| |
| location l2: |
| edge e when 1 = 1 now goto l1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = l1, l2; |
| |
| automaton M: |
| alphabet p_e; |
| event p_e; |
| |
| disc E p = l1; |
| disc bool u = true; |
| |
| initial p = l1 and true or p = l2 and false; |
| marked p = l1 and false or p = l2 and false; |
| |
| plant invariant u; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge p_e when p = l1 and true do p := l2; |
| edge p_e when p = l2 and 1 = 1 do p := l1; |
| |
| edge when p = l1 or p = l2 and 1 = 1 now do u := false; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>So, if <code>p</code> (the location pointer variable for original automaton <code>p</code>) is |
| equal to <code>l1</code> (the enumeration literal for original location <code>l1</code>), then |
| the guard of the new urgent edge is enabled, and time may not progress. |
| Similarly, if <code>p</code> is equal to <code>l2</code> and the guard <code>1 = 1</code> of the original |
| urgent edge is enabled, the guard of the new urgent edge is enabled, and time |
| may not progress. This correctly reflects the urgency conditions of the |
| original specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To ensure that no additional event transitions are possible, the new urgent |
| edge can never be taken, as it would update <code>u</code> to <code>false</code>, which violates |
| <code>plant invariant u</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-received-values-and-tuple-field-projections-2">Received values and tuple field projections</h7> |
| <div class="paragraph"> |
| <p>The following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event tuple(int a, b) e; |
| |
| automaton s: |
| location: |
| edge e!(1, 2); |
| end |
| |
| automaton r: |
| disc int x; |
| location: |
| edge e? do x := ?[a]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">event e; |
| enum E = X; |
| |
| automaton M: |
| alphabet e; |
| |
| disc E s in any; |
| disc int r_x; |
| disc E r in any; |
| |
| initial s = X and false, |
| r = X and false; |
| marked s = X and false, |
| r = X and false; |
| |
| location L: |
| initial; |
| marked; |
| |
| edge e when s = X and r = X do r_x := (1, 2)[0]; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Observe how event <code>e</code> no longer has a data type, and the communication (send |
| and receive) have been eliminated. In the assignment <code>x := ?[a]</code>, received |
| value <code>?</code> has been replaced by send value <code>(1, 2)</code>. Since tuple values |
| don’t have field names, the right hand side <code>(1, 2)[a]</code> has been replaced |
| by <code>(1, 2)[0]</code>, using the <a href="#tools-cif2cif-chapter-elim-tuple-field-projs">Eliminate tuple field projections</a> CIF to |
| CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect6"> |
| <h7 id="tools-elimination-of-communication-2">Elimination of communication</h7> |
| <div class="paragraph"> |
| <p>Since channel communication is completely eliminated, and channels become |
| regular events after this transformation, it is no longer possible to |
| <a href="#tools-chapter-mergecif">merge</a> additional senders/receivers with the linearized |
| specification. If you wish to merge another specification with additional |
| communication partners, first perform the merging, and then the linearization.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-linearize-product-renaming">Renaming</h6> |
| <div class="paragraph"> |
| <p>Since declarations are moved/merged, and new names are introduced, renaming may |
| be necessary to ensure unique names within a single scope. In order to reduce |
| the amount of renaming for the enumeration literals introduced for the |
| locations of the original automata, all enumerations are merged together into a |
| single enumeration in the specification, with name <code>E</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If renaming is performed, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-cif2cif-linearize-product-size">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Declarations are moved, so they don’t increase the size of the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The addition of location variables increases the size of the specification, but |
| this is linear in the number of automata and the number of locations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Assignment are added for the updates to the location pointers. The increase is |
| linear in the number of edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since <code>tau</code> edges are essentially just moved, they don’t increase the size |
| of the specification. That is, their size is linear in the number of original |
| <code>tau</code> edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Multiple self loops may be added for non-<code>tau</code> event, and thus may result in |
| an exponential blow up of the number of edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The initialization and marker predicates, as well as the invariants are moved. |
| They remain linear in size related to the number of original predicates. The |
| predicates for the locations are also made conditional on the values of the |
| location pointer variable. This size increase is linear in the number of |
| original locations. Predicates are combined using boolean operators, leading |
| to a size increase that is linear in the number of original predicates.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If a single received value is used multiple times in the updates of a single |
| edge, the send value is duplicated for each of those uses. As such, the size |
| increase is linear in the number of uses of the received value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For urgency, an additional variable and invariant are added. This is a constant |
| increase in size. A self loop is added as well. This self loop duplicates |
| the guards of urgent edges. It also includes predicates for the urgent |
| locations. The size of this edge is linear in the number of urgent locations, |
| and the guards of the urgent edges.</p> |
| </div> |
| <div class="paragraph"> |
| <p>From the above, it should be clear that due to the exponential blow up of the |
| edges, linearization results can be significantly larger than the original |
| specifications.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-20">Optimality</h6> |
| <div class="paragraph"> |
| <p>As should be clear from the examples above, this transformation does not try |
| to generate optimized expressions. In fact, often almost all generated |
| expressions can easily be simplified. To further simplify the result, apply |
| additional CIF to CIF transformations, such as |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Currently, no effort is made by this transformation to reduce for instance the |
| number of replacements of tuple field projections by tuple index projections.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-merge-enums">Merge enumerations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation merges all enumerations together to a single |
| enumeration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See also: <a href="#tools-cif2cif-chapter-elim-enums">Eliminate enumerations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-31">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-28">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>To increase the subset of specifications that can be transformed, apply |
| the following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order) prior to using this transformation:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| automatically applied as preprocessing (in the given order), to increase the |
| subset of CIF specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-20">Implementation details</h6> |
| <div class="paragraph"> |
| <p>If there are any enumerations in the specification, a single new enumeration |
| is created. This enumeration is named <code>E</code>. All literals of the original |
| enumerations are added to this new enumeration. Obviously, duplicate literals |
| are only included once. The literals are added in sorted order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The original enumerations are removed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum A = B, C; |
| |
| automaton p: |
| enum A = C, B; |
| enum X = D, C; |
| disc A a = C; |
| disc X x = D; |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = B, C, D; |
| |
| automaton p: |
| disc E a = C; |
| disc E x = D; |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-17">Renaming</h6> |
| <div class="paragraph"> |
| <p>The newly created enumeration <code>E</code> and its literals, may conflict with |
| declarations already present in the specification. If this is the case, they |
| are renamed. For instance, if <code>E</code> is already in use, <code>E2</code>, or <code>E3</code>, etc, |
| is used instead. If renaming is performed, a warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, renaming of enumeration literals may influence value equality for |
| <em>compatible</em> enumerations (enumerations with the same number of literals, with |
| the same names, in the same order). However, since the resulting specification |
| has at most one enumeration, there are no multiple enumerations, and thus |
| compatibility is not an issue (since the enumeration is always compatible with |
| itself).</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-default-initial-values">Default initial values</h6> |
| <div class="paragraph"> |
| <p>Consider the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group g1: |
| enum e1 = A, B; |
| end |
| |
| group g2: |
| enum e2 = B, A; |
| end |
| |
| automaton p: |
| disc g1.e1 v1; |
| disc g2.e2 v2; |
| |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>If we apply merging of enumerations directly, we get the following:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">enum E = A, B; |
| |
| group g1: |
| end |
| |
| group g2: |
| end |
| |
| automaton p: |
| disc E v1; |
| disc E v2; |
| |
| location: |
| initial; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the original specification, <code>v1</code> had value <code>A</code>, and <code>v2</code> had value |
| <code>B</code>. After the merging of the enumerations, both <code>v1</code> and <code>v2</code> have |
| implicit initial value <code>A</code>. Thus, they had different initial values |
| beforehand, and the same initial values afterward. To solve this problem, the |
| <a href="#tools-cif2cif-chapter-add-default-init-values">Add default initial values</a> CIF to CIF transformation is |
| automatically applied as preprocessing before the actual elimination of the |
| enumerations, to ensure that the explicit initial values are properly |
| transformed.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-19">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since enumerations are merged, duplicate literals become a single new literal. |
| Therefore, this transformation may decrease the size of the specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The added default initial values may significantly increase the size of the |
| specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-21">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-print-file-into-decls">Push print file declarations into print declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This CIF to CIF transformation pushes |
| <a href="#tools-cifsim-output-print-chapter-ref-printfile">print file declarations</a> |
| inwards into the |
| <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print declarations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-32">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-29">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-21">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All <a href="#tools-cifsim-output-print-chapter-ref-printfile">print file declarations</a> |
| specified in the top level scope of the specification, in groups, and in |
| automata, are removed. The |
| <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print declarations</a> to which |
| they applied, each get a local print file declaration instead. If they already |
| had a local print file declaration, the print declaration is not changed. |
| Print declarations to which no print file declaration applies, get the default |
| target <code>":stdout"</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, this specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">printfile "out1.txt"; |
| |
| print 5; |
| print 6 file "out2.txt"; |
| |
| group g: |
| printfile "out3.txt"; |
| |
| print 7; |
| print 8; |
| print 9 file "out4.txt"; |
| |
| group h: |
| printfile "out5.txt"; |
| end |
| |
| group i: |
| print 10; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">print 5 file "out1.txt"; |
| print 6 file "out2.txt"; |
| |
| group g: |
| print 7 file "out3.txt"; |
| print 8 file "out3.txt"; |
| print 9 file "out4.txt"; |
| |
| group h: |
| end |
| |
| group i: |
| print 10 file "out3.txt"; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The print declaration that prints <code>5</code> is declared in the top level scope of |
| the specification, and does not have a local print file declaration. As such, |
| the print file declaration from the top level scope (<code>out1.txt</code>) is pushed |
| inwards into the print declaration. The print declaration that prints <code>6</code> is |
| declared in the same scope, but already has a local print file declaration |
| (<code>out2.txt</code>), and is thus not changed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g</code> also has an print file declaration (<code>out3.txt</code>). This is pushed |
| inwards to the print declarations that print <code>7</code> and <code>8</code>, as they are |
| declared in the same scope, and don’t have local print file declarations. The |
| print declaration that prints <code>9</code> is not changed, as it already has a local |
| print file declaration (<code>out4.txt</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The print file declaration (<code>out5.txt</code>) from group <code>g.h</code> does not apply to |
| any print declarations, and thus gets lost.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g.i</code> does not have an print file declaration, so the print declaration |
| that prints <code>10</code>, which is declared in that group, gets the print file |
| declaration from group <code>g</code> (the parent scope of group <code>g.i</code>) instead.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-18">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-20">Size considerations</h6> |
| <div class="paragraph"> |
| <p>As print file declarations may apply to multiple print declarations, this |
| transformation may increase the number of (local) print file declarations in |
| the specification. The number of print file declarations after the |
| transformation is at most the number of print declarations, and as such the |
| increase is at most linear in the number of print declarations as well.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-22">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-svg-file-into-decls">Push SVG file declarations into other CIF/SVG declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This CIF to CIF transformation pushes |
| <a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declarations</a> inwards into |
| the other <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-33">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-30">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-22">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All <a href="#tools-cifsim-output-svgviz-chapter-svgfile">SVG file declarations</a> |
| specified in the top level scope of the specification, in groups, and in |
| automata, are removed. The other |
| <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a> to which they |
| apply, each get a local SVG file declaration instead. If they already had a |
| local SVG file declaration, the CIF/SVG declaration is not changed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>For instance, this specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgfile "file1.svg"; |
| |
| svgout id "a" attr "b" value 5; |
| |
| svgout id "c" attr "d" value 6 file "file2.svg"; |
| |
| group g: |
| svgfile "file3.svg"; |
| |
| svgout id "e" attr "f" value 7; |
| |
| svgout id "g" attr "h" value 8; |
| |
| svgout id "i" attr "j" value 9 file "file4.svg"; |
| |
| group h: |
| svgfile "file5.svg"; |
| end |
| |
| group i: |
| svgout id "k" attr "l" value 10; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>is transformed to the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">svgout id "a" attr "b" value 5 file "file1.svg"; |
| |
| svgout id "c" attr "d" value 6 file "file2.svg"; |
| |
| group g: |
| svgout id "e" attr "f" value 7 file "file3.svg"; |
| |
| svgout id "g" attr "h" value 8 file "file3.svg"; |
| |
| svgout id "i" attr "j" value 9 file "file4.svg"; |
| |
| group h: |
| end |
| |
| group i: |
| svgout id "k" attr "l" value 10 file "file3.svg"; |
| end |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The mapping for the SVG element with id <code>a</code> is declared in the top level |
| scope of the specification, and does not have a local SVG file declaration. |
| As such, the SVG file declaration from the top level scope (<code>file1.svg</code>) is |
| pushed inwards into the mapping. The mapping for the SVG element with id <code>b</code> |
| is declared in the same scope, but already has a local SVG file declaration |
| (<code>file2.svg</code>), and is thus not changed.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g</code> also has an SVG file declaration (<code>file3.svg</code>). This is pushed |
| inwards to the mappings for ids <code>e</code> and <code>g</code>, as they are declared in the |
| same scope, and don’t have local SVG file declarations. The mapping for SVG |
| element id <code>i</code> is not changed, as it already has a local SVG file declaration |
| (<code>file4.svg</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SVG file declaration (<code>file5.svg</code>) from group <code>g.h</code> does not apply to |
| any mappings, and thus gets lost.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Group <code>g.i</code> does not have an SVG file declaration, so the mapping for SVG |
| element id <code>k</code>, which is declared in that group, gets the SVG file |
| declaration from group <code>g</code> (the parent scope of group <code>g.i</code>) instead.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-19">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-21">Size considerations</h6> |
| <div class="paragraph"> |
| <p>As SVG file declarations may apply to multiple other CIF/SVG declarations, this |
| transformation may increase the number of SVG file declarations in the |
| specification. The number of SVG file declarations after the transformation is |
| at most the number of 'other' CIF/SVG declarations, and as such the increase is |
| at most linear in the number of 'other' CIF/SVG declarations as well.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-23">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-remove-cif-svg-decls">Remove CIF/SVG declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation removes |
| <a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG</a> declarations from the |
| specification. This may reduce the size of the specification. It may also lead |
| to the specification being supported by more tools, as the CIF/SVG declarations |
| may use features of the CIF language that certain tools don’t support.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This CIF to CIF transformation removes only CIF/SVG declarations. The |
| <a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a> CIF to CIF transformation removes them |
| as well, but additionally also removes the other I/O declarations.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-34">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-31">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-23">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All CIF/SVG declarations are removed from the specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-20">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-22">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since information is removed from the specification, the specification can only |
| become smaller as a result of this transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-24">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation removes I/O declarations from the specification. |
| This may reduce the size of the specification. It may also lead to the |
| specification being supported by more tools, as the I/O declarations may use |
| features of the CIF language that certain tools don’t support.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-35">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-32">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-24">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All I/O declarations are removed from the specification. I/O declarations |
| include:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-printdecl">Print declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-print-chapter-ref-printfile">Print file declaration</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cifsim-output-svgviz-chapter-cifsvg">CIF/SVG declarations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation removes all I/O declarations. To only remove certain kinds |
| of I/O declarations, see the following CIF to CIF transformations:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-print-decls">Remove print declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-cif-svg-decls">Remove CIF/SVG declarations</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-21">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-23">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since information is removed from the specification, the specification can only |
| become smaller as a result of this transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-25">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-remove-print-decls">Remove print declarations</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| This CIF to CIF transformation removes |
| <a href="#tools-cifsim-output-print-chapter-ref-printdecl">print</a> and |
| <a href="#tools-cifsim-output-print-chapter-ref-printfile">print file</a> declarations |
| from the specification. This may reduce the size of the specification. It may |
| also lead to the specification being supported by more tools, as the print and |
| print file declarations may use features of the CIF language that certain tools |
| don’t support.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This CIF to CIF transformation removes only print and print file declarations. |
| The <a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a> CIF to CIF transformation removes |
| them as well, but additionally also removes the other I/O declarations.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-36">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-33">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-25">Implementation details</h6> |
| <div class="paragraph"> |
| <p>All print and print file declarations are removed from the specification.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-22">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-24">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since information is removed from the specification, the specification can only |
| become smaller as a result of this transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-26">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-remove-pos-info">Remove position information</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation removes position information from the internal |
| representation of the specification.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-37">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports all CIF specifications.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-34">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-26">Implementation details</h6> |
| <div class="paragraph"> |
| <p>When performing operations on CIF specifications, the specification is first |
| read from disk, and stored into memory. The internal representation |
| stores position information with all objects (such as declarations, |
| types, expression nodes, automata, locations, etc). The position information of |
| an object includes information about the location of the object in the original |
| textual source. This information is used during validation of the specification |
| (i.e. type checking), when reporting errors, to indicate where in the original |
| specification the error is found.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| After type checking, this information is no longer used. To make sure that |
| subsequent operations, such as CIF to CIF transformations, don’t have to |
| process the position information, this transformation can be applied to rid |
| the specification of all position information. Applying this transformation |
| may increase the performance of subsequent transformations.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Applying this transformation has no effect on the actual contents of the |
| specification, and does not change the effect of subsequent transformation. |
| That is, it may affect the performance of subsequent transformations, but has |
| no effect on the result of the subsequent transformations, as they are written |
| to disk.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-23">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-25">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since position information is removed from the specification, this |
| transformation has an effect on the size of the specification as it is |
| represented in memory. However, this transformation has no effect on the size |
| of the specification, as far as actual content (which affects the meaning of |
| the specification) is concerned.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-27">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-remove-reqs">Remove requirements</h5> |
| <div class="paragraph"> |
| <p> |
| |
| |
| This CIF to CIF transformation removes |
| <a href="#lang-tut-extensions-synthesis-plant-req-sup">requirements</a> from the |
| specification. By removing all requirements from a CIF specification with both |
| <a href="#lang-tut-extensions-synthesis-plant-req-sup">plants</a> and requirements, only the |
| plants remain. The resulting plants can then be <a href="#tools-chapter-mergecif">merged</a> |
| with a <a href="#lang-tut-extensions-synthesis-plant-req-sup">supervisor</a> or other |
| controller.</p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-38">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| <li> |
| <p>Using (referring to) requirement automata or declarations from requirement |
| automata from outside requirement automata.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Specifications where requirement automata or declarations declared in |
| requirement automata are used (referred to) from outside requirement automata |
| are not supported. By removing the requirement automata, those uses |
| (references) become invalid, as the automata or declarations that are |
| referenced no longer exist. For instance, consider:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg int x = switch req: case l1: 1 else 2 end; |
| |
| requirement automaton req: |
| location l1: |
| initial; |
| edge tau goto l2; |
| |
| location l2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>When requirement automaton <code>req</code> is removed, the <code>switch</code> expression can no |
| longer refer to that automaton, or to its locations. Removing the requirements |
| from this CIF specification is not supported.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-35">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-27">Implementation details</h6> |
| <div class="paragraph"> |
| <p>Both <a href="#lang-tut-extensions-synthesis-autkind">requirement automata</a> and |
| <a href="#lang-tut-extensions-synthesis-invkind">requirement invariants</a> are |
| removed. Requirement invariants are removed from the top level scope of the |
| specification, all groups and automata, and all locations of automata. For |
| instance, consider the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">controllable add; |
| |
| plant automaton buffer: |
| disc int x; |
| |
| plant invariant 0 <= x and x <= 5; |
| requirement invariant x < 5; |
| |
| location: |
| initial; |
| plant invariant x >= 0; |
| edge add do x := x + 1; |
| end |
| |
| requirement automaton not2: |
| location: |
| initial; |
| requirement invariant buffer.x >= 0; |
| edge add when buffer.x != 2; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The result after this transformation is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">controllable add; |
| |
| plant automaton buffer: |
| disc int x; |
| |
| plant invariant 0 <= x and x <= 5; |
| |
| location: |
| initial; |
| plant invariant x >= 0; |
| edge add do x := x + 1; |
| end</code></pre> |
| </div> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-24">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-26">Size considerations</h6> |
| <div class="paragraph"> |
| <p>Since information is removed from the specification, the specification can only |
| become smaller as a result of this transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-28">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-simplify-others">Simplify others</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation simplifies CIF specifications, by applying |
| the following non-value related simplifications:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Duplicate monitor events of automata are removed.</p> |
| </li> |
| <li> |
| <p>Duplicate events in the alphabet are removed.</p> |
| </li> |
| <li> |
| <p>Duplicate events on edges are removed, with the exception of duplicate sends |
| for the same event, as they may send different values.</p> |
| </li> |
| <li> |
| <p>Self-loops with a target location are simplified by removing the target |
| location.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-39">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-36">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-28">Implementation details</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-25">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-27">Size considerations</h6> |
| <div class="paragraph"> |
| <p>This transformation tries to simplify the specification, possibly reducing its |
| size.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-29">Optimality</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-simplify-values">Simplify values</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation simplifies CIF specifications, by applying |
| the following value-related simplifications:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Evaluation of constant (sub-)expressions. For instance, <code>1 + 1</code> is |
| simplified to <code>2</code>.</p> |
| </li> |
| <li> |
| <p>Simplification of short-circuit boolean binary operators. For instance, |
| <code>true and x</code> is simplified to <code>x</code>.</p> |
| </li> |
| <li> |
| <p>Simplification of boolean unary operators. For instance, <code>not not x</code> is |
| simplified to <code>x</code>.</p> |
| </li> |
| <li> |
| <p>Removal of default values. For instance, <code>true</code> state invariants are |
| removed.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-40">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-37">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-29">Implementation details</h6> |
| <div class="paragraph"> |
| <p>The following is a complete list of the short-circuit boolean binary operators |
| that are simplified (with <code>x</code> an arbitrary boolean expression):</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Original</th> |
| <th class="tableblock halign-left valign-top">Simplified</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true and x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x and true</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false and x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x and false</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true or x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x or true</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false or x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x or false</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true => x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x => true</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false => x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x => false</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>true <=> x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x <=> true</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>false <=> x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x <=> false</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not x</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>The following is a complete list of the boolean unary operators that are |
| simplified (with <code>x</code> and <code>y</code> two arbitrary expressions):</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Original</th> |
| <th class="tableblock halign-left valign-top">Simplified</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not not x</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x < y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x >= y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x <= y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x > y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x = y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x != y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x != y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x = y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x > y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x ⇐ y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x >= y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x < y</code></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>not(x => y)</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>x and not y</code></p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>Default values are removed in the following places:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Initialization predicates of components (including automata) and locations.</p> |
| </li> |
| <li> |
| <p>Marker predicates of components (including automata) and locations.</p> |
| </li> |
| <li> |
| <p>Invariants of components (including automata) and locations.</p> |
| </li> |
| <li> |
| <p>Guards of edges.</p> |
| </li> |
| <li> |
| <p>Guards of 'if' and 'elif' updates on edges.</p> |
| </li> |
| <li> |
| <p>Guards of 'if' and 'elif' expressions.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Predicates that are trivially equal to the default value are removed. If a |
| trivial value is found that is equal to the negation of the default value, the |
| entire feature gets the non-default value. For instance, for guards on edges, |
| <code>true</code>, <code>1 = 1</code>, etc, are removed as they are all trivially <code>true</code> |
| (the default for guards). If however, <code>false</code>, <code>1 = 2</code>, <code>1 != 1</code>, or any |
| other trivially <code>false</code> guards is found, all guards on that edge are removed, |
| and a single <code>false</code> guard is added.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-26">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-28">Size considerations</h6> |
| <div class="paragraph"> |
| <p>This transformation tries to simplify the specification, possibly reducing its |
| size.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All uses of constants lead to constant (sub-)expressions, and they are |
| evaluated. This leads to constants being inlined. For constants with large |
| literal values, this may significantly increase the size of the specification, |
| especially if the constant is used more than once. For information on how to |
| prevent this, see the <a href="#tools-cif2cif-chapter-simplify-values-no-refs">Simplify values (no references)</a> CIF to CIF |
| transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-30">Optimality</h6> |
| <div class="paragraph"> |
| <p>Not all simplifications that could potentially be performed are implemented in |
| this transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-simplify-values-optimized">Simplify values (optimized)</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation simplifies CIF specifications, by applying |
| same value-related simplifications as the <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> |
| CIF to CIF transformation, but with optimizations for literal expressions.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-41">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-38">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-30">Implementation details</h6> |
| <div class="paragraph"> |
| <p>One of the simplifications that the CIF to CIF transformation to |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> performs, is the evaluation of constant |
| (sub-)expressions. For large literal expressions, such as arrays with thousands |
| or even millions of elements, this is expensive, without having any effect. |
| For instance, consider list/array literal <code>[1, 2, 3]</code>. Evaluating the |
| list/array and the integer elements, and then reconstructing the literal |
| list/array expression and literal integer expressions, has no effect. The |
| result is the same list/array literal as the original.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation detects literal expressions, and doesn’t further simplify |
| them, thus greatly improving performance for large literal expressions. |
| Literal expressions are detected using a static analysis. Due to using static |
| analysis, some literals may not be simplified, while they would have been |
| simplified if this literal detection optimization was not used. For instance, |
| a set literal <code>{1, 2, 1}</code> is simplified to <code>{1, 2}</code> without optimizations, |
| and is not simplified with optimizations. In this case, static analysis does |
| not account for duplicate elements of the set.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following differences can be observed for literal optimization, with |
| respect to not using literal optimization:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Negations of integer literals are not normalized, although this only affects |
| the internal representation of negative integer values, and may not be |
| externally visible to end users.</p> |
| </li> |
| <li> |
| <p>Real literals are not normalized. For instance, <code>1e3</code> is not normalized |
| to <code>1000.0</code>.</p> |
| </li> |
| <li> |
| <p>For set literals, duplicate elements are not removed.</p> |
| </li> |
| <li> |
| <p>For dictionary literals, duplicate keys are not removed, and the dictionary |
| literal is not further simplified. Without literal optimization, duplicate |
| keys would lead to an error during simplification.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-27">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-29">Size considerations</h6> |
| <div class="paragraph"> |
| <p>This transformation tries to simplify the specification, possibly reducing its |
| size.</p> |
| </div> |
| <div class="paragraph"> |
| <p>All uses of constants lead to constant (sub-)expressions, and they are |
| evaluated. This leads to constants being inlined. For constants with large |
| literal values, this may significantly increase the size of the specification, |
| especially if the constant is used more than once. For information on how to |
| prevent this, see the <a href="#tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</a> |
| CIF to CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-31">Optimality</h6> |
| <div class="paragraph"> |
| <p>Not all simplifications that could potentially be performed are implemented in |
| this transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The optimizations for literals that are performed influence the optimality of |
| the simplification, as described above.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-simplify-values-no-refs">Simplify values (no references)</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation simplifies CIF specifications, by applying |
| same value-related simplifications as the <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> |
| CIF to CIF transformation, but without simplifying reference expressions.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-42">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-39">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-31">Implementation details</h6> |
| <div class="paragraph"> |
| <p>The CIF to CIF transformation to <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a>, |
| transforms the following specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 3; |
| invariant x - 5 + 1 > 0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>into the following simplified specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 3; |
| invariant false;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This transformation however, does not take the values of declarations into |
| account, and thus for instance does not fill in the values of constants, |
| algebraic variables, etc. Therefore, this transformation transforms that same |
| specification into the following simplified specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">const int x = 3; |
| invariant x - 4 > 0;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This variant can be useful, as it prevents the use of constants from being |
| eliminated. This makes it possible to change the value of the constant in one |
| place (the one place being the declaration of the constant), and have all uses |
| of that constant automatically change with it (as they still refer to the |
| constant). If the value of the constant would be filled in as well, changing |
| the value of the constant would be more work, as all those places where it was |
| filled in, need to be replaced as well. In the above example, the issue is |
| even bigger, as the result is simplified even further, eliminating the entire |
| comparison to a single boolean value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another issue related to simplification of constants, is that inlining them |
| can be very expensive. If a constant has a large literal as its value, the |
| large literal is inlined wherever the constant is used. This may lead to |
| significantly larger specifications. Also, tools that use the resulting model |
| may handle constants in a special way to ensure they are evaluated only once, |
| but may not do so for large literals that occur in the middle of other |
| expressions. As such, simplification/inlining of constants may significantly |
| reduce performance.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The reference expressions that are not simplified (filled in) include among |
| others the following:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Values of constants.</p> |
| </li> |
| <li> |
| <p>Values of discrete variables.</p> |
| </li> |
| <li> |
| <p>Values of algebraic variables.</p> |
| </li> |
| <li> |
| <p>Values of continuous variables.</p> |
| </li> |
| <li> |
| <p>Values of input variables.</p> |
| </li> |
| <li> |
| <p>Derivatives of continuous variables.</p> |
| </li> |
| <li> |
| <p>Values of local variables of functions.</p> |
| </li> |
| <li> |
| <p>Values of parameters of functions.</p> |
| </li> |
| <li> |
| <p>User-defined functions.</p> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-28">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-30">Size considerations</h6> |
| <div class="paragraph"> |
| <p>This transformation tries to simplify the specification, possibly reducing its |
| size.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-32">Optimality</h6> |
| <div class="paragraph"> |
| <p>Not all simplifications that could potentially be performed are implemented in |
| this transformation.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</h5> |
| <div class="paragraph"> |
| <p> |
| |
| This CIF to CIF transformation simplifies CIF specifications, by applying |
| same value-related simplifications as the <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> |
| CIF to CIF transformation, but without simplifying reference expressions, and |
| with optimizations for literal expressions.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-supported-specifications-43">Supported specifications</h6> |
| <div class="paragraph"> |
| <p>This transformation supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-preprocessing-40">Preprocessing</h6> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-implementation-details-32">Implementation details</h6> |
| <div class="paragraph"> |
| <p>This CIF to CIF transformation simplifies CIF specifications, by applying |
| same value-related simplifications as the |
| <a href="#tools-cif2cif-chapter-simplify-values">Simplify values</a> CIF to CIF transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>However, it does not simplifying reference expressions. For details, see the |
| <a href="#tools-cif2cif-chapter-simplify-values-no-refs">Simplify values (no references)</a> CIF to CIF transformation. |
| Furthermore, it simplifies with optimizations for literal expressions. For |
| details, see the <a href="#tools-cif2cif-chapter-simplify-values-optimized">Simplify values (optimized)</a> CIF to CIF |
| transformation.</p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-renaming-29">Renaming</h6> |
| <div class="paragraph"> |
| <p>n/a</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-size-considerations-31">Size considerations</h6> |
| <div class="paragraph"> |
| <p>This transformation tries to simplify the specification, possibly reducing its |
| size.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect5"> |
| <h6 id="tools-optimality-33">Optimality</h6> |
| <div class="paragraph"> |
| <p>Not all simplifications that could potentially be performed are implemented in |
| this transformation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The optimizations for literals that are performed influence the optimality of |
| the simplification, as described above.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-mergecif">CIF merger</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF merger can be used to merge two or more CIF specifications into a |
| single CIF specification. The result of the merger is essentially the parallel |
| composition of the input specifications. Unlike the |
| <a href="#tools-chapter-cif-explorer">CIF explorer</a> and <a href="#tools-eventbased-chapter-product">Event-based synchronous product</a> tools |
| however, the parallel composition is not unfolded into a |
| <a href="#tools-cifsim-traces-state-space">state space</a>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It can for instance be useful to merge a synthesized supervisor with a timed or |
| hybrid plant, to validate the supervisor against that more detailed plant, |
| using interactive simulation and visualization on the merged specification.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The specifications that are being merged can <a href="#tools-mergecif-shared">share</a> |
| events and variables, making it possible to have |
| interaction between the merged specifications.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-transformation-7">Starting the transformation</h5> |
| <div class="paragraph"> |
| <p>The merger can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Use the Eclipse IDE to merge multiple files:</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Select a <code>.cif</code> file in the 'Project Explorer' tab or |
| 'Package Explorer' tab by left clicking on it.</p> |
| </li> |
| <li> |
| <p>Select additional <code>.cif</code> files by left clicking on them while pressing |
| the |
| <kbd>Ctrl</kbd> |
| or |
| <kbd>Control</kbd> |
| key.</p> |
| </li> |
| <li> |
| <p>Make sure at least two <code>.cif</code> files are selected.</p> |
| </li> |
| <li> |
| <p>Right click one of the <code>.cif</code> files and choose |
| <b class="menuref">Merge CIF specifications…​</b>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Use the Eclipse IDE to merge a single file with itself (allowed, but |
| practically not that useful):</p> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Right click a <code>.cif</code> file in the 'Project Explorer' tab or |
| 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Merge CIF specifications…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Merge CIF specifications…​</b></span>.</p> |
| </li> |
| </ul> |
| </div> |
| </li> |
| <li> |
| <p>Use the <code>cifmerge</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifmerge</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-options-20">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input files</em>: The absolute or relative local file system path to the |
| input CIF specifications. These are the files to merge.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| merged/output CIF specification. If not specified, the output file defaults |
| to <code>merged.cif</code>. If the merger is executed via the Eclipse GUI, the output |
| file, if specified as a relative path (or just a file name), is resolved |
| relative to the directory that contains the first input file.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-41">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>The following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are |
| applied as preprocessing (in the given order), to increase the subset of CIF |
| specifications that can be transformed:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-svg-file-into-decls">Push SVG file declarations into other CIF/SVG declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-print-file-into-decls">Push print file declarations into print declarations</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>If only one input file is provided to the CIF merger, essentially that single |
| input file is preprocessed and written as output, without any merging taking |
| place.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-example-4">Example</h5> |
| <div class="paragraph"> |
| <p>Consider the following supervisor:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group button: |
| uncontrollable u_pushed, u_released; |
| end |
| |
| group lamp: |
| controllable c_on, c_off; |
| end |
| |
| group timer: |
| controllable c_start; |
| uncontrollable u_timeout; |
| end |
| |
| supervisor automaton timed_lamp: |
| location s0: |
| initial; |
| edge button.u_pushed goto s1; |
| edge button.u_released; |
| |
| location s1: |
| edge lamp.c_on goto s2; |
| edge button.u_pushed, button.u_released; |
| |
| location s2: |
| edge timer.c_start goto s3; |
| edge button.u_pushed, button.u_released; |
| |
| location s3: |
| edge timer.u_timeout goto s4; |
| edge button.u_pushed, button.u_released; |
| |
| location s4: |
| edge lamp.c_off goto s0; |
| edge button.u_pushed, button.u_released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>and the following timed plant:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton button: |
| uncontrollable u_pushed, u_released; |
| |
| location released: |
| initial; |
| edge u_pushed goto pushed; |
| |
| location pushed: |
| edge u_released goto released; |
| end |
| |
| plant automaton lamp: |
| controllable c_on, c_off; |
| |
| location off: |
| initial; |
| edge c_on goto on; |
| |
| location on: |
| edge c_off goto off; |
| end |
| |
| plant automaton timer: |
| controllable c_start; |
| uncontrollable u_timeout; |
| |
| cont t der 1.0; |
| |
| location idle: |
| initial; |
| edge c_start do t := 0.0 goto running; |
| |
| location running: |
| edge u_timeout when t >= 2.0 goto idle; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Merging these two specifications results in the following merged specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton button: |
| uncontrollable u_pushed; |
| uncontrollable u_released; |
| location released: |
| initial; |
| edge u_pushed goto pushed; |
| location pushed: |
| edge u_released goto released; |
| end |
| plant automaton lamp: |
| controllable c_on; |
| controllable c_off; |
| location off: |
| initial; |
| edge c_on goto on; |
| location on: |
| edge c_off goto off; |
| end |
| plant automaton timer: |
| controllable c_start; |
| uncontrollable u_timeout; |
| cont t der 1.0; |
| location idle: |
| initial; |
| edge c_start do t := 0.0 goto running; |
| location running: |
| edge u_timeout when t >= 2.0 goto idle; |
| end |
| supervisor automaton timed_lamp: |
| location s0: |
| initial; |
| edge button.u_pushed goto s1; |
| edge button.u_released; |
| location s1: |
| edge lamp.c_on goto s2; |
| edge button.u_pushed, button.u_released; |
| location s2: |
| edge timer.c_start goto s3; |
| edge button.u_pushed, button.u_released; |
| location s3: |
| edge timer.u_timeout goto s4; |
| edge button.u_pushed, button.u_released; |
| location s4: |
| edge lamp.c_off goto s0; |
| edge button.u_pushed, button.u_released; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The supervisor specification contains three <em>skeletons</em>: groups that only |
| contain event declarations, and have no behavior. The skeletons represent the |
| plants of the system, which are controlled by the supervisor. The supervisor |
| specification also contains a supervisor automaton, which waits for the button |
| to be pushed, then turns on the lamp and start the timer, waits for the timer |
| to time out, turns the lamp back off, and keeps repeating this behavior. |
| Pushing or releasing the button during the cycle has no effect.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The timed specification contains the same plants, with the same events, but |
| here the plants are actual automata with behavior, instead of just skeleton |
| groups. For the button and lamp, the events occur in alternating sequences. |
| The timer has a clock that ensures that the timeout happens two time units |
| after the timer is started.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Since both specifications contain the same events (based on their absolute |
| names), these events are merged together. This ensures that uses of those |
| events become linked (or coupled), and all refer to the single merged event in |
| the merged specification. This means that the events used in the supervisor are |
| the same events as used the timed plant. This also means that they synchronize, |
| and the supervisor thus controls the timed plants.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| </p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-mergecif-shared">Shared events and variables</h5> |
| <div class="paragraph"> |
| <p>The example above shows how shared events can be used to link (or couple) |
| multiple specifications through merging.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Similarly to the way events can be merged, it is possible to merge input |
| variables with other variables, as long as the types are compatible. That is, |
| an input variable can be merged with another input variable, a discrete |
| variable, a continuous variable, an algebraic variable, a constant, or a |
| location. The input variable is then a sort of <em>skeleton</em> definition that is |
| merged with an actual definition (for instance an algebraic variable), which |
| defines the value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>There are thus two ways for merged specifications to become linked (or |
| coupled): by means of shared events and by means of shared variables (including |
| constants).</p> |
| </div> |
| <div class="paragraph"> |
| <p>For further details and restrictions, see the |
| <a href="#tools-mergecif-compatibility">Merge compatibility</a> section.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-mergecif-compatibility">Merge compatibility</h5> |
| <div class="paragraph"> |
| <p>In general, objects (components, declarations, etc) that only occur in one |
| of the specifications being merged, are simply copied to the merged |
| specification. If in two (or more) specifications objects with the same |
| absolute name are present, they need to be merged. Not all objects can be |
| merged with all other objects, i.e. not all objects are <em>merge compatible</em>. |
| The following table gives an overview of what can be merged:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6923%;"> |
| <col style="width: 7.6924%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Merge with</th> |
| <th class="tableblock halign-left valign-top">Group</th> |
| <th class="tableblock halign-left valign-top">Automaton</th> |
| <th class="tableblock halign-left valign-top">Event</th> |
| <th class="tableblock halign-left valign-top">Input var</th> |
| <th class="tableblock halign-left valign-top">Discrete var</th> |
| <th class="tableblock halign-left valign-top">Continuous var</th> |
| <th class="tableblock halign-left valign-top">Algebraic var</th> |
| <th class="tableblock halign-left valign-top">Constant</th> |
| <th class="tableblock halign-left valign-top">Location</th> |
| <th class="tableblock halign-left valign-top">Type declaration</th> |
| <th class="tableblock halign-left valign-top">Enumeration</th> |
| <th class="tableblock halign-left valign-top">Enumeration literal</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Group</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Automaton</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Event</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Input var</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Discrete var</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Continuous var</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Algebraic var</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Constant</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Location</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Type declaration</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Enumeration</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Enumeration literal</strong></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p>For components (i.e. groups and automata) that are present in more than one |
| specification, the contents are recursively merged into a single component. |
| The contents of components consists not only of their declarations (such as |
| events) and their sub-components (for groups), but also of their invariants, |
| initialization predicates, marker predicates, equations, locations |
| (for automata), etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>As the button/lamp example above shows, automata can be merged with groups |
| (often acting as skeletons), resulting in an automaton with the contents of |
| the group merged into it. Since automata can’t contain sub-components and |
| user-defined functions, groups with sub-components and/or user-defined |
| functions can not be merged with automata.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Groups can also be merged with other groups. Automata however can not be merged |
| with other automata, as that may lead to the merge of conflicting behavioral |
| specifications.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Events can be merged with other events. Each event must then either be a |
| channel in all of the specifications in which it occurs, or in none of them. |
| If it is a channel, the data type must be exactly the same in all |
| specifications in which it is declared. Events that have different |
| controllability in different specifications, can also not be merged.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Constants can be merged with other constants. However, the constants must then |
| have the exact same type and value in all the specifications in which they |
| occur. This restriction prevents the merge of conflicting values. Due to this |
| restriction, constants that have a type of which the values can not be compared |
| for equality (e.g. function types), are not supported (can not be merged).</p> |
| </div> |
| <div class="paragraph"> |
| <p>As mentioned in the <a href="#tools-mergecif-shared">Shared events and variables</a> section, an input variable can |
| be merged with another input variable, discrete variable, continuous variable, |
| algebraic variable, constant, or location. Input variables can only be merged |
| with other objects that have the exact same type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A location can be merged with an input variable that has a boolean type. The |
| input variable is then a placeholder for the location, indicating whether the |
| location is the current location of its automaton.</p> |
| </div> |
| <div class="paragraph"> |
| <p>It is not allowed to merge two algebraic variables, two discrete variables, or |
| two continuous variables, as that may lead to the merge of conflicting values.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In general, only one of the specifications defines the variable as a concrete |
| variable that defines a value (e.g. as a discrete, continuous, or algebraic |
| variable). All the other specifications that have that same variable must |
| declare it as an input variable (essentially a <em>placeholder</em>). It is however |
| allowed to merge two or more constants with the same type and the same value.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Type declarations can be merged with other type declarations, as long as they |
| have the exact same type.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Enumerations can be merged with other enumerations, as long as they are |
| compatible. Two enumerations are compatible if they have the same number of |
| literals, with the exact same names, in the same order.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Enumeration literals can only be merged as the result of the enumerations of |
| which they are a part being merged. Merging two literals from different |
| enumerations (which then have different names) is not supported.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Type declarations and enumerations can be merged, as long as the type of the |
| type declaration is compatible with the enumeration.</p> |
| </div> |
| <div class="paragraph"> |
| <p>User-defined functions can never be merged with other objects of the same name.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-invariants-2">Invariants</h5> |
| <div class="paragraph"> |
| <p>Merging a group with an automaton, may change the supervisory kinds of the |
| invariants of the group. For instance, consider the following CIF |
| specifications:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">group x: |
| input int y; |
| invariant y = 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton x: |
| disc int y; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>When merged, this leads to the following CIF specification:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">plant automaton x: |
| disc int y; |
| invariant y = 1; |
| end</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>In the original group <code>x</code>, the invariant did not have a supervisory kind. |
| After merging, the invariant still does not specify a supervisory kind. |
| However, since it is now specified in an automaton <code>x</code> of kind <code>plant</code>, the |
| invariant <a href="#lang-tut-extensions-synthesis-invkind-implicit">implicitly</a> |
| becomes a plant invariant as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>When an invariant gets an implicit supervisory kind as a result of merging, |
| the merge tool prints a warning to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To get rid of the warning, the invariant in group <code>x</code> can be declared |
| explicitly as being a <code>plant</code> invariant. The supervisory kind then matches |
| the supervisory kind of automaton <code>x</code>. When the group and automaton are |
| merged, the invariant keeps its explicit supervisory <code>plant</code> kind. The merge |
| result is thus the same as the earlier merge result, as in both cases the |
| invariant in the merged specification is interpreted as a print invariant. |
| However, in this last case, no warning is printed to the console.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-merge-problems">Merge problems</h5> |
| <div class="paragraph"> |
| <p>Even when two or more CIF specifications are merge compatible, as described |
| above, the resulting merged CIF specification can still be invalid. In such |
| cases, merging fails. For instance, consider the following two CIF |
| specifications:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">input int x; |
| alg int y = x;</code></pre> |
| </div> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg int x = y; |
| input int y;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>Merging them would result in:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="cif">alg int x = y; |
| alg int y = x;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>But this merged specification is invalid, as <code>x</code> is defined in terms of |
| <code>y</code>, which is defined in terms of <code>x</code>, leading to a loop (definition/use |
| cycle).</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another example of merge problems is two CIF specifications that have SVG |
| output mappings for the same SVG element id and attribute, for the same SVG |
| image file. In the individual CIF specifications there are no duplicate output |
| mappings, but in the merged specification there are.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-event-disabler">CIF event disabler</h4> |
| <div class="paragraph"> |
| <p> |
| |
| The CIF event disabler tool can be used to disable certain events of a CIF |
| specification, or even to disable events not currently present in a CIF |
| specification. The tool has various <a href="#tools-event-disabler-options">options</a> that can be used to control the working of the |
| tool, and influence its output.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-event-disabler-usage-scenario">Usage scenario</h5> |
| <div class="paragraph"> |
| <p>Assume a system with some sensors and actuators. From the view of the |
| supervisor (or controller in general), the sensors are uncontrollable, and the |
| actuators are controllable. Now assume a controller is being designed for this |
| system, and it is to be merged with a simulation model of the uncontrolled |
| system, that is being designed as well.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The situation may arise that the controller only controls a part of the |
| uncontrolled system. This may for instance be the case if the designer of the |
| controller starts with a small controller and incrementally extends it to cover |
| more and more functionality of the system. The designer may have already made |
| a full simulation model of the uncontrolled system beforehand. Alternatively, |
| if one designer develops the controller and another develops the simulation |
| model of the uncontrolled system, the simulation model may be finished well |
| before the controller for the entire system is finished.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A problem arises when a controller that controls only part of the system, is |
| merged with a simulation model of the entire uncontrolled system. In the |
| uncontrolled system, the actuators can usually be turned on and off |
| arbitrarily, as they are not yet controlled in any way. If the controller |
| doesn’t control certain actuators, the behavior of those actuators is not |
| restricted, and during simulation the events to turn the actuators on and off |
| can happen at any time. Events are urgent, that is, they take precedence over |
| passage of time, and thus happen 'immediately'. Events that are always enabled |
| thus prevent passage of time. The simulation will turn the actuators on, off, |
| on again, off again, etc.</p> |
| </div> |
| <div class="paragraph"> |
| <p>To solve this problem, the controllable events of the uncontrolled system that |
| are not restricted in any way by the controller need to be disabled. The CIF |
| event disabler tool makes this possible.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This is however not the only usage scenario. The same controller may be used |
| for implementation. For the implementation, a mapping from events to variables |
| that represent the I/O ports may be needed. This mapping could be a CIF |
| specification, with an automaton that performs the mapping. Similar to having |
| a complete simulation model, a complete mapping specification for the |
| implementation may be available. If in such mappings the actuator events are |
| always enabled, this may lead to similar problems as for the simulation, if |
| the controller only controls part of the system. Here too, the event disabler |
| can be used to restrict such actuator events from causing trouble.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-tool">Starting the tool</h5> |
| <div class="paragraph"> |
| <p>The tool can be started in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>In Eclipse, right click a <code>.cif</code> file in the 'Project Explorer' tab |
| or 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Disable events of CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>In Eclipse, right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Disable events of CIF specification…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifevtdis</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifevtdis</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-44">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The event disabler supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Component definitions and component instantiations are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-42">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>No preprocessing is currently performed by this CIF to CIF transformation. To |
| increase the subset of specifications that can be transformed, apply the |
| following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> (in the |
| given order):</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-event-disabler-options">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, this application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file</em>: The absolute or relative local file system path to the |
| input CIF specification. If we relate this to the above |
| <a href="#tools-event-disabler-usage-scenario">usage scenario</a>, the input file should be the |
| controller that only controls part of the system.</p> |
| </li> |
| <li> |
| <p><em>Output file</em>: The absolute or relative local file system path to the |
| output CIF specification. If not specified, defaults to the input file |
| path, where the <code>.cif</code> file extension is removed (if present), and a |
| <code>.disabled.cif</code> file extension is added.</p> |
| </li> |
| <li> |
| <p><em>Event names</em>: The absolute names of the events. How these supplied events |
| are used depends on the <em>Event usage</em> option. Multiple events may be |
| specified, separated by commas and/or spaces.</p> |
| </li> |
| <li> |
| <p><em>Event names file</em>: The absolute or relative local file system path of a file |
| with the absolute names of the events. How these supplied events are used |
| depends on the <em>Event usage</em> option. Multiple events may be specified in the |
| file, on separate lines. Empty lines are ignored. Lines starting with a <code>#</code> |
| character are ignored as well, and can thus be used to add comments.</p> |
| </li> |
| <li> |
| <p><em>SVG input events</em>: Enable this option to use the SVG input events. How the |
| events are used depends on the <em>Event usage</em> option.</p> |
| </li> |
| <li> |
| <p><em>Event usage</em>: This option can be used to specify how the supplied events are |
| to be used. That is, it specifies which events to disable. See the |
| <a href="#tools-event-disabler-spec-evts-to-disable">Specifying the events to disable</a> section for more |
| information.</p> |
| </li> |
| <li> |
| <p><em>Include input specification</em>: Should the output file contain only the new |
| automaton that is created to disable the events, or should it include the |
| input specification as well? See the |
| <a href="#tools-event-disabler-output">Output</a> section for more information.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>At least one of the <em>Event names</em>, <em>Event names file</em>, or <em>SVG input events</em> |
| options must be used to supply events to the tool. It is allowed to use |
| multiple of these options, to combine events from multiple sources, and supply |
| all of them to the tool.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-event-disabler-spec-evts-to-disable">Specifying the events to disable</h5> |
| <div class="paragraph"> |
| <p>The <em>Event names</em>, <em>Event names file</em>, and <em>SVG input events</em> options can be |
| used to supply events to the tool. How these events are used (or interpreted) |
| depends on the <em>Event usage</em> option. Several alternatives are available:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Disable the supplied events, regardless of the alphabet of the input |
| specification (<code>disable</code>)</p> |
| </li> |
| <li> |
| <p>Disable all supplied events, that are not in the alphabet of the input |
| specification (<code>alphabet</code>)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The texts between parentheses at the end of the alternatives indicate the |
| command line option values that correspond with the alternatives. The default |
| is <code>alphabet</code>.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The most straightforward alternative is to manually specify the events to |
| <code>disable</code> (the first alternative in the above list). The supplied events are |
| then disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Manually specifying the events to disable can be cumbersome. Especially if the |
| controller is developed incrementally, this can be a burden. The more events |
| the controller does restrict, the less events should be disabled using the |
| event disabler. In this case it may be easier to list the controllable events |
| of the uncontrolled system that the controller may or may not restrict. That |
| is, the <code>alphabet</code> (the second alternative in the above list) of controllable |
| events of the uncontrolled system is specified. Supplied events that are not |
| in the alphabet of any of the automata of the input specification, are |
| disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following table summarizes which events get disabled by the tool:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 25%;"> |
| <col style="width: 25%;"> |
| <col style="width: 25%;"> |
| <col style="width: 25%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">Event usage</th> |
| <th class="tableblock halign-left valign-top">Event supplied</th> |
| <th class="tableblock halign-left valign-top">Event in alphabet</th> |
| <th class="tableblock halign-left valign-top">Event is disabled by tool</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">disable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes/no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">disable</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes/no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">alphabet</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">alphabet</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes</p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">alphabet</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">yes/no</p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td> |
| </tr> |
| </tbody> |
| </table> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-event-disabler-output">Output</h5> |
| <div class="paragraph"> |
| <p>If the <em>Include input specification</em> option is enabled, the output |
| specification is a copy of the input specification, which is then modified to |
| disable certain events. For events that are disabled by the tool, but did not |
| exist in the input specification, an event declaration is added. If the option |
| is disabled, the output specification starts empty. For all events are |
| disabled, an event declaration is added. Event declarations are added in |
| their proper scopes, based on their absolute names, by adding groups around |
| them as needed.</p> |
| </div> |
| <div class="paragraph"> |
| <p> |
| |
| By default, the <em>Include input specification</em> option is disabled. This ensures |
| that the output specification is small. The typical scenario is to merge the |
| input specification, event disabler output specification, and simulation model |
| together using the <a href="#tools-chapter-mergecif">CIF merger</a> tool. Disabling the <em>Include input |
| specification</em> specification option then gives the best performance for the |
| tool chain.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If any events are disabled by the tool, a new automaton is created, and this |
| automaton is added to the output specification. The automaton is named |
| <code>event_disabler</code>, but may be renamed if it conflicts with an already existing |
| object with the same name. The automaton has no supervisory kind, and has the |
| disabled events as alphabet. It has a single nameless location, with a single |
| self loop for all of the events that are disabled. The guard of the self |
| loop is <code>false</code>, which results in the events being globally disabled.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If the <em>Include input specification</em> option is enabled, and events are disabled |
| that did not exist in the input specification, event declarations are added to |
| the output specification for those events. If the <em>Include input specification</em> |
| option is disabled, event declarations are added for all events that are |
| disabled. Event declarations that are added and existed in the input |
| specification (in case the <em>Include input specification</em> option is disabled), |
| inherit their controllability from the input specification. All other events |
| that are added are declared as controllable events if their name starts with |
| <code>c_</code>, are declared as uncontrollable events if their name starts with <code>u_</code>, |
| and are declared as neither controllable nor uncontrollable otherwise.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-chapter-cif-explorer">CIF explorer</h4> |
| <div class="paragraph"> |
| <p> |
| |
| |
| |
| |
| The CIF explorer unfolds the state space expressed by a CIF specification, in |
| an untimed setting. It takes a CIF model and iteratively explores the states |
| using event transitions, unfolding the state space. Available output forms |
| include a CIF automaton of the state space, and a report with details of the |
| found states. Time transitions are never taken. The explorer will return a |
| deadlock state when forced into a time step. Continuous variables are allowed, |
| but behave much like discrete variables due to lack of time steps.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-starting-the-program">Starting the program</h5> |
| <div class="paragraph"> |
| <p>The explorer can be started in Eclipse in the following ways:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Right click a <code>.cif</code> file in the 'Project Explorer' tab or |
| 'Package Explorer' tab and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Explore untimed state space…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Right click an open text editor for a <code>.cif</code> file and choose |
| <span class="menuseq"><b class="menu">CIF miscellaneous tools</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Explore untimed state space…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifexplorer</code> tool in a |
| ToolDef script. See the |
| <a href="#tools-scripting-chapter-intro">scripting documentation</a> and |
| <a href="#tools-scripting-chapter-tools">tools overview</a> page for details.</p> |
| </li> |
| <li> |
| <p>Use the <code>cifexplorer</code> command line tool.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-options-21">Options</h5> |
| <div class="paragraph"> |
| <p>Besides the general application options, the application has the following |
| options:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><em>Input file path</em>: The absolute or relative file system path to the input |
| CIF specification.</p> |
| </li> |
| <li> |
| <p><em>Enable edge minimization</em>: Enable edge minimization to remove duplicate |
| edges of the state space, before printing statistics, and writing output |
| files. Two edges are duplicates if they have the same source and target |
| states, and the same event. The communication value, if any, is ignored. |
| Enabled by default.</p> |
| </li> |
| <li> |
| <p><em>Enable statistics</em>: Enable printing of statistics of the resulting state |
| space to the console. Statistics include the number of states and the number |
| of edges of the resulting state space. It is recommended to enable the |
| edge minimization option when printing statistics. Enabled by default.</p> |
| </li> |
| <li> |
| <p><em>Enable CIF output</em>: Enable output of states and edges as a CIF automaton. |
| Enabled by default.</p> |
| </li> |
| <li> |
| <p><em>Output file path</em>: The absolute or relative file system path of the output |
| CIF specification with the generated state space as a CIF automaton.</p> |
| </li> |
| <li> |
| <p><em>Enable report</em>: Enable writing a detailed report on the found states. |
| Disabled by default.</p> |
| </li> |
| <li> |
| <p><em>Report file path</em>: The absolute or relative file system path of the report |
| file. If specified, option <em>Enable report</em> is implied.</p> |
| </li> |
| <li> |
| <p><em>Print progress</em>: The number of states to process before printing progress |
| information. Must be a non-negative integer number. May be <code>off</code> to disable |
| progress information. The default is to print progress information after |
| processing 1000 states.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The CIF output file is written if the <em>Enable CIF output</em> option is set, or if |
| a path is supplied with the <em>Output file path</em> option. If the latter is given, |
| its value is used as the path for writing the report file. If only the |
| <em>Enable CIF output</em> option is set, the value of the <em>Input file path</em> option is |
| used, where the <code>.cif</code> extension is removed (if present), and |
| a <code>_statespace.cif</code> suffix is added.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The report file is written if the <em>Enable report</em> option is set, or if a path |
| is supplied with the <em>Report file path</em> option. If the latter is given, its |
| value is used as the path for writing the report file. If only the |
| <em>Enable report</em> option is set, the value of the <em>Input file path</em> option is |
| used, where the <code>.cif</code> extension is removed (if present), and |
| a <code>_report.txt</code> suffix is added.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If both the CIF output and the report file output are disabled, the resulting |
| state space is not outputted at all. In such cases, the state space explorer |
| acts as a verifier for runtime errors, which can make the exploration fail. |
| If exploration completes without errors, the explorer has verified that no |
| runtime errors occur. Runtime errors include failures to compute values, such |
| as division by zero, as well as assignments that assign values to variables |
| that are outside the allowed bounds/ranges of the variables.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-supported-specifications-45">Supported specifications</h5> |
| <div class="paragraph"> |
| <p>The explorer supports a subset of CIF specifications. The following |
| restrictions apply:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Usage of distribution types and distribution standard library functions is |
| not supported.</p> |
| </li> |
| <li> |
| <p>Usage of derivatives is not supported.</p> |
| </li> |
| <li> |
| <p>External user-defined functions are not supported.</p> |
| </li> |
| <li> |
| <p>Input variables are not supported.</p> |
| </li> |
| <li> |
| <p>Specifications with more than 2<sup>31</sup> - 1 = 2,147,483,647 potential |
| initial states are not supported.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The following information from the specification is ignored:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Automaton and invariant supervisory kinds.</p> |
| </li> |
| <li> |
| <p>Controllability of events.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-preprocessing-43">Preprocessing</h5> |
| <div class="paragraph"> |
| <p>Prior to exploration, the following <a href="#tools-cif2cif-chapter-index">CIF to CIF transformations</a> are applied as preprocessing (in the given order), to |
| increase the subset of CIF specifications that can be explored:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-remove-io-decls">Remove I/O declarations</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-comp-def-inst">Eliminate component definition/instantiation</a></p> |
| </li> |
| <li> |
| <p><a href="#tools-cif2cif-chapter-elim-self">Eliminate automaton <code>self</code> references</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>In addition it applies the |
| <a href="#tools-cif2cif-chapter-simplify-values-no-refs-optimized">Simplify values (no references, optimized)</a> CIF to CIF |
| transformation to speed up processing.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="tools-scripting">Scripting</h3> |
| <div class="sect3"> |
| <h4 id="tools-scripting-chapter-intro">Introduction to scripting</h4> |
| <div class="paragraph"> |
| <p>All CIF <a href="#tools-chapter-index">tools</a> can be used in |
| ToolDef scripts. ToolDef is a |
| cross-platform and machine-independent scripting language that supports command |
| line execution, but is also available as plug-in for |
| <a href="https://eclipse.org">Eclipse</a>, providing an integrated development |
| experience.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-scenarios">Scenarios</h5> |
| <div class="paragraph"> |
| <p>Using CIF tools in a ToolDef script can be useful for various reasons.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Scripts allow executing multiple tools, one after the other, for instance to |
| perform <a href="#tools-chapter-datasynth">data-based synthesis</a> on some sub-systems, |
| <a href="#tools-chapter-mergecif">merge</a> the resulting supervisors, and |
| <a href="#tools-cif2plc-chapter-index">generate PLC code</a> from it. Once a script is made, |
| these steps can be easily repeated whenever the models for the sub-systems |
| change. This is much easier than starting each of the tools manually, and saves |
| valuable time. Furthermore, it is possible to share your script with others, |
| who can then perform the same steps, and get the same results.</p> |
| </div> |
| <div class="paragraph"> |
| <p>A script can also be used to execute a single tool, specifying the parameters |
| used when executing it. For instance, a script could execute the simulator, |
| specifying not only which model (file) to simulate, but also the simulation |
| options. If various <a href="#tools-cifsim-output-chapter-index">visualizations</a> are |
| enabled, variables are <a href="#tools-cifsim-output-plotviz-filtering">filtered</a>, |
| etc, manually configuring the options for each simulation can become tiresome. |
| By specifying them in a script, simulating again with the same options becomes |
| as simple as executing the script again. By sharing such a script with others, |
| they can simulate the same model with the same options.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Another use of scripts is to repeatedly execute the same tool, but with |
| different parameters. A good example is |
| <a href="#tools-cifsim-chapter-repeated-simulation">repeatedly simulating</a> a model. |
| Instead of manually simulating a model with |
| <a href="#tut-stochastics-chapter-intro">stochastics</a> hundreds or even thousands of |
| times, which can be very time consuming, a script can be used to automate this |
| task. The script can then also be used to automatically collect the results, |
| and process them. Others can use the same script to repeat the experiments and |
| verify the results, or to perform similar experiments.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-library-import">Library import</h5> |
| <div class="paragraph"> |
| <p>In order to use CIF tools in a ToolDef script, the library with all CIF |
| tools needs to be imported. The import statement to use is:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *;</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This statement imports all tools from the <code>cif</code> library, a library |
| registered by the CIF tooling. You’ll want to include this import statement |
| in all your own scripts that use CIF tools.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-execution-a-tool">Execution a tool</h5> |
| <div class="paragraph"> |
| <p>Here is a simple example of a ToolDef script that simulates a model using the |
| <a href="#tools-cifsim-chapter-index">CIF simulator</a>:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim("some_model.cif -i auto -t 10");</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The second statement executes the <code>cifsim</code> tool (the CIF simulator). This |
| is just one of the tools that is available, but there are |
| <a href="#tools-scripting-chapter-tools">many more</a>.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-command-line-arguments">Command line arguments</h5> |
| <div class="paragraph"> |
| <p>Command line arguments can be used to let a tool know on which files it should |
| operate, and what options it should use. The example above uses |
| <code>"some_model.cif -i auto -t 10"</code> as arguments, consisting of the model to |
| simulate (the <code>some_model.cif</code> file) and some simulation options |
| (<a href="#tools-cifsim-input-chapter-automatic">automatic simulation</a> due to |
| <code>-i auto</code>, and a simulation |
| <a href="#tools-cifsim-termination-endtime">end time</a> of 10 time units due to |
| <code>-t 10</code>).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The command line options to use in ToolDef, are identical to the command line |
| options to use for command line scripts, in a |
| shell or command window. The CIF documentation generally refers to command line |
| arguments or command line options, which can thus be used on the actual command |
| line, as well as in ToolDef scripts.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The command line arguments that are available are different for each tool. All |
| CIF tools have <code>-h</code> and <code>--help</code> command line arguments that can be used |
| to print the application help text to the console. The help text contains |
| detailed information on all the command line arguments supported by the tool. |
| Here is an example of how to show the help text for the simulator:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim("-h");</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>This information can also be seen in the option dialog:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/scripting/option_dialog_cmdline_help.png" alt="option dialog cmdline help"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The option dialog shows the same help text as the command line <code>--help</code> and |
| <code>-h</code> options. In this screenshot, you can see the help text of the |
| <code>--end-time</code> or <code>-t</code> option. This particular option can also be configured |
| using the option dialog. It is part of the |
| <b class="menuref">Simulator</b> |
| category:</p> |
| </div> |
| <div class="imageblock"> |
| <div class="content"> |
| <img src="./tools/scripting/option_dialog_cmdline_link.png" alt="option dialog cmdline link"> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>There, it is listed as |
| <b class="menuref">Simulator end time</b> |
| option. After that name, |
| the command line names of the option (<code>--end-time</code> and <code>-t</code>) are also |
| listed. This makes it easier to link options in the option dialog with command |
| line options.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In the example ToolDef scripts so far, all command line arguments are provided |
| as a single string of text. However, it is also possible to provide each |
| command line argument as a separate string. In fact, you may provide as many |
| strings as you like, and each string may contain as many command line arguments |
| as you like. For instance, the following statements each execute the simulator, |
| and all have the same command line arguments, but provided in a different way:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">cifsim("some_model.cif -i auto -t 10"); // Single string, all arguments. |
| cifsim("some_model.cif", "-i auto", "-t 10"); // Multiple strings, multiple arguments each. |
| cifsim("some_model.cif", "-i", "auto", "-t", "10"); // Multiple strings, one argument each.</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>For simulations, disabling a certain simulation option is a common task. By |
| listing each simulation option on a separate line of the script, disabling or |
| enabling a simulation option becomes as easy as commenting or uncommenting a |
| line of the script. For instance, consider the following script:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim( |
| "some_model.cif", |
| "-i auto", |
| "-t 10", |
| );</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The model to simulate, the enabling of the automatic input mode, and the |
| simulation end time, are each specified on a separate line. This makes it very |
| easy to disable the simulation end time:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim( |
| "some_model.cif", |
| "-i auto", |
| // "-t 10", |
| );</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>To comment a line or multiple selected lines in a ToolDef text editor, use |
| keyboard shortcut <span class="keyseq"><kbd>Ctrl</kbd>+<kbd>/</kbd></span> or the corresponding toolbar button |
| (<span class="image"><img src="./tools/scripting/comment.png" alt="comment"></span>). For uncommenting, use keyboard shortcut |
| <span class="keyseq"><kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>/</kbd></span> or the corresponding toolbar button |
| (<span class="image"><img src="./tools/scripting/uncomment.png" alt="uncomment"></span>).</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-output-redirection-and-other-options">Output redirection and other options</h5> |
| <div class="paragraph"> |
| <p>Besides the application specific options that can be configured using the |
| command line arguments, all tools such as the <code>cifsim</code> tool, have some |
| additional options. This includes the possibility to write the output of the |
| tool to a file instead of the console:</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">from "lib:cif" import *; |
| |
| cifsim("some_model.cif -i auto -t 10", stdout="output.txt");</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The <code>stdout</code> parameter of the <code>cifsim</code> tool is used to specify the |
| filename of the file to which to write the output. A complete list of the |
| available parameters and their meaning, is available on the |
| <a href="#tools-scripting-chapter-tools">Overview of scriptable tools</a> page.</p> |
| </div> |
| </div> |
| </div> |
| <div class="sect3"> |
| <h4 id="tools-scripting-chapter-tools">Overview of scriptable tools</h4> |
| <div class="paragraph"> |
| <p>This page provides an overview of the CIF tools that are available in the |
| <code>cif</code> library that is registered with ToolDef by CIF.</p> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-tools">Tools</h5> |
| <div class="paragraph"> |
| <p>The following table shows the relation between the names of the ToolDef tools |
| in the library and the tools of the CIF tool set:</p> |
| </div> |
| <table class="tableblock frame-all grid-all stretch"> |
| <colgroup> |
| <col style="width: 50%;"> |
| <col style="width: 50%;"> |
| </colgroup> |
| <thead> |
| <tr> |
| <th class="tableblock halign-left valign-top">ToolDef tool name</th> |
| <th class="tableblock halign-left valign-top">CIF tool</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2yed</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-cif2yed">CIF to yEd transformer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifdatasynth</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-datasynth">Data-based supervisory controller synthesis</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2supremica</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-cif2supremica">CIF to Supremica transformer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifsim</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cifsim-chapter-index">CIF simulator</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2mcrl2</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-cif2mcrl2">CIF to mCRL2 transformer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2uppaal</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-cif2uppaal">CIF to UPPAAL transformer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifcodegen</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-codegen-chapter-index">CIF code generator</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2plc</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cif2plc-chapter-index">CIF PLC code generator</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cif2cif</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-cif2cif-chapter-index">CIF to CIF transformer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifmerge</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-mergecif">CIF merger</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifevtdis</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-event-disabler">CIF event disabler</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifexplorer</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-chapter-cif-explorer">CIF explorer</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifprod</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-product">Event-based synchronous product</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifsupsynth</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-supervisorsynthesis">Event-based supervisor synthesis</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifsynthanalys</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-synthesis-analysis">Event-based synthesis analysis</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifncchk</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-nonconflicting-check">Event-based nonconflicting check</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifctrlchk</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-controllability-check">Event-based controllability check</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ciflngeqv</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-language-equivalence-check">Event-based language equivalence check</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifnfadfa</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-nfa-to-dfa">Event-based NFA to DFA automaton conversion</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifdfamin</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-dfa-minimization">Event-based DFA minimization</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifproj</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-projection">Event-based automaton projection</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifobschk</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-observer-check">Event-based observer check</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>cifabstr</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-automaton-abstraction">Event-based automaton abstraction</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ciftrimchk</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-trim-check">Event-based trim check</a></p></td> |
| </tr> |
| <tr> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ciftrim</code></p></td> |
| <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#tools-eventbased-chapter-trim">Event-based trim</a></p></td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-parameters">Parameters</h5> |
| <div class="paragraph"> |
| <p>For every CIF tool, two ToolDef tool variants are available in the <code>cif</code> |
| ToolDef library. All the CIF tools in the <code>cif</code> ToolDef library have |
| the same tool signatures, including the same parameters. Only their names |
| differ. Below the tool signatures for the two variants are listed, with |
| <code>toolname</code> instead of the actual tool name (e.g. <code>cifsim</code>):</p> |
| </div> |
| <div class="listingblock"> |
| <div class="content"> |
| <pre class="CodeRay highlight"><code data-lang="tooldef">tool int toolname( |
| string... args, |
| string stdin = "-", |
| string stdout = "-", |
| string stderr = "-", |
| bool appendOut = false, |
| bool appendErr = false, |
| bool errToOut = false, |
| bool ignoreNonZeroExitCode = false |
| ) |
| |
| tool int toolname( |
| list string args = [], |
| string stdin = "-", |
| string stdout = "-", |
| string stderr = "-", |
| bool appendOut = false, |
| bool appendErr = false, |
| bool errToOut = false, |
| bool ignoreNonZeroExitCode = false |
| )</code></pre> |
| </div> |
| </div> |
| <div class="paragraph"> |
| <p>The meaning of each of the parameters is as follows:</p> |
| </div> |
| <div class="dlist"> |
| <dl> |
| <dt class="hdlist1">args</dt> |
| <dd> |
| <p>The command line arguments of the application. Each argument string is parsed |
| to zero or more actual arguments. It is possible to use a single string with |
| all arguments (where the arguments themselves are separated by spaces), comma |
| separated strings for each of the arguments (each string has one argument), |
| or a mix of those.</p> |
| <div class="paragraph"> |
| <p>In argument strings, individual arguments are separated by whitespace |
| (spaces, tabs, new lines, etc). The whitespace itself is ignored, and only |
| serves as separation. To include whitespace in an argument, the argument (or |
| a part of it), may be quoted, by putting it between double quotes (<code>"</code>) or |
| single quotes (<code>'</code>). Characters may be escaped by prefixing them with a |
| backslash (<code>\</code>). This is particularly useful for single/double quotes, and |
| escape characters, and can also be used to escape spaces. Escapes work the |
| same inside of quoted parts as they do outside of quoted parts.</p> |
| </div> |
| </dd> |
| <dt class="hdlist1">stdin</dt> |
| <dd> |
| <p>Specify whether to have a standard input (stdin) stream and where the input |
| comes from. Use <code>""</code> to not have a stdin stream, "-" to use the stdin |
| stream of the ToolDef interpreter, or otherwise an absolute or relative local |
| file system path of the file from which to read the standard input. May |
| contain both <code>\</code> and <code>/</code> as path separators</p> |
| </dd> |
| <dt class="hdlist1">stdout</dt> |
| <dd> |
| <p>Specify whether to have a standard output (stdout) stream and where to write |
| the standard output. Use <code>""</code> to not have a stdout stream, <code>"-"</code> to use |
| the stdout stream of the ToolDef interpreter, or otherwise an absolute or |
| relative local file system path of the file to which to write the standard |
| output. May contain both <code>\</code> and <code>/</code> as path separators.</p> |
| </dd> |
| <dt class="hdlist1">stderr</dt> |
| <dd> |
| <p>Specify whether to have a standard error (stderr) stream and where to write |
| the standard error output. Use <code>""</code> to not have a stderr stream, <code>"-"</code> |
| to use the stderr stream of the ToolDef interpreter, or otherwise an absolute |
| or relative local file system path of the file to which to write the standard |
| error output. May contain both <code>\</code> and <code>/</code> as path separators. Is ignored |
| when the standard error stream is redirected to the standard output stream.</p> |
| </dd> |
| <dt class="hdlist1">appendOut</dt> |
| <dd> |
| <p>Whether to append to the stdout file (<code>true</code>) or overwrite it (<code>false</code>). |
| Is ignored when standard output is not written to a file.</p> |
| </dd> |
| <dt class="hdlist1">appendErr</dt> |
| <dd> |
| <p>Whether to append to the stderr file (<code>true</code>) or overwrite it (<code>false</code>). |
| Is ignored if standard error output is not written to a file. Is also ignored |
| when standard error stream is redirected to the standard output stream.</p> |
| </dd> |
| <dt class="hdlist1">errToOut</dt> |
| <dd> |
| <p>Whether to redirect the standard error stream to the standard output stream |
| (<code>true</code>) or use separate streams (<code>false</code>).</p> |
| </dd> |
| <dt class="hdlist1">ignoreNonZeroExitCode</dt> |
| <dd> |
| <p>Whether to ignore non-zero exit codes (<code>true</code>) or consider them as errors |
| (<code>false</code>).</p> |
| </dd> |
| </dl> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-return-value">Return value</h5> |
| <div class="paragraph"> |
| <p>All the tools return an integer value. This value is the exit code of the |
| application. A zero (<code>0</code>) exit code means the application terminated without |
| any errors. A non-zero exit code means the application terminated with an |
| error.</p> |
| </div> |
| </div> |
| <div class="sect4"> |
| <h5 id="tools-implementation">Implementation</h5> |
| <div class="paragraph"> |
| <p>All the tools are internally implemented using the ToolDef <code>app</code> tool.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="examples-chapter-index">CIF examples</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>CIF ships with several examples. To obtain these examples, follow these steps:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Start the Eclipse ESCET IDE.</p> |
| </li> |
| <li> |
| <p>Click <span class="menuseq"><b class="menu">File</b> <i class="fa fa-angle-right caret"></i> <b class="submenu">New</b> <i class="fa fa-angle-right caret"></i> <b class="menuitem">Example…​</b></span>.</p> |
| </li> |
| <li> |
| <p>Select <em>CIF Examples</em> and click <b class="button">Next</b>.</p> |
| </li> |
| <li> |
| <p>Choose the name of the new project that will be created.</p> |
| </li> |
| <li> |
| <p>Choose a location for the new project, on your hard disk. If you leave the |
| <em>Use default location</em> option enabled, the new project will be created in |
| workspace directory. See the Eclipse ESCET documentation for more |
| information on workspaces.</p> |
| </li> |
| <li> |
| <p>Click <b class="button">Finish</b> to create the new project, and fill it with the |
| examples.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>For new releases of CIF, the examples may change. The examples project that you |
| previously created won’t be automatically updated. You can however go |
| through the steps again, and get a second project, with the new examples. The |
| version of the release is included in the suggested project name, allowing |
| multiple example projects for different releases.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Most examples also include a ToolDef <a href="#tools-scripting-chapter-intro">script</a> |
| (<code>.tooldef</code> file) that can be used to perform various tasks, such as |
| simulation. To execute such a script, right click a <code>.tooldef</code> file an choose |
| <b class="menuref">Execute ToolDef</b>. Alternatively, select the file and press |
| <kbd>F10</kbd>.</p> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="release-notes-chapter-index">CIF release notes</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The release notes for the releases of CIF and the associated tools, as |
| part of the Eclipse ESCET project, are listed below in reverse chronological |
| order.</p> |
| </div> |
| <div class="sect2"> |
| <h3 id="version-0-1-unreleased">Version 0.1 (unreleased)</h3> |
| <div class="paragraph"> |
| <p>The first release of CIF as part of the Eclipse ESCET project.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="dev-chapter-index">Developers</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The CIF developers manual is intended only for those who develop or extend |
| the CIF language or tools. It is not intended for end users.</p> |
| </div> |
| <div class="paragraph"> |
| <p>This manual only contains CIF specific information. For general developers |
| information, see the Eclipse ESCET developers manual.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The following information is available for developers:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p><a href="#dev-lang-modify">CIF language modification</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="sect2"> |
| <h3 id="dev-lang-modify">CIF language modification</h3> |
| <div class="paragraph"> |
| <p>For each change to the CIF language, follow these steps:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Update <code>cif.setext</code> syntax.</p> |
| </li> |
| <li> |
| <p>Update <code>cif.bnf</code> syntax in documentation.</p> |
| </li> |
| <li> |
| <p>Update example models for changed syntax.</p> |
| </li> |
| <li> |
| <p>Update Ecore metamodel. Update Ecore diagram images.</p> |
| </li> |
| <li> |
| <p>Update Ecore genmodel. Remove and re-generate model code.</p> |
| </li> |
| <li> |
| <p>Update generated Java constructors and walker code.</p> |
| </li> |
| <li> |
| <p>Update LaTeX documentation skeleton files.</p> |
| </li> |
| <li> |
| <p>Update LaTeX documentation, including constraints. Generate new PDF.</p> |
| </li> |
| <li> |
| <p>Update example models for changed constraints.</p> |
| </li> |
| <li> |
| <p>Update parser implementation, including AST classes.</p> |
| </li> |
| <li> |
| <p>Update text editor, including keywords and syntax highlighting.</p> |
| </li> |
| <li> |
| <p>Update type checker, including error message enumeration.</p> |
| </li> |
| <li> |
| <p>Update pretty printer, including set of keywords.</p> |
| </li> |
| <li> |
| <p>Update CIF to CIF transformations and other tools.</p> |
| </li> |
| <li> |
| <p>Update CIF documentation, including language reference manual with lexical |
| syntax and grammar.</p> |
| </li> |
| <li> |
| <p>Update CIF syntax highlighting definition for LaTeX.</p> |
| </li> |
| <li> |
| <p>Update CIF syntax highlighting definition for AsciiDoctor.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p></p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div class="sect1"> |
| <h2 id="legal-chapter-index">Legal</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The material in this documentation is |
| Copyright (c) 2010, 2020 Contributors to the Eclipse Foundation.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Eclipse ESCET and ESCET are trademarks of the Eclipse Foundation. |
| Eclipse, and the Eclipse Logo are registered trademarks of the |
| Eclipse Foundation. Other names may be trademarks of their |
| respective owners.</p> |
| </div> |
| <div class="paragraph"> |
| <p><strong>License</strong></p> |
| </div> |
| <div class="paragraph"> |
| <p>The Eclipse Foundation makes available all content in this document |
| ("Content"). Unless otherwise indicated below, the Content is provided to you |
| under the terms and conditions of the MIT License. A copy of the MIT License |
| is available at <a href="https://opensource.org/licenses/MIT" class="bare">https://opensource.org/licenses/MIT</a>. For purposes of the |
| MIT License, "Software" will mean the Content.</p> |
| </div> |
| <div class="paragraph"> |
| <p>If you did not receive this Content directly from the Eclipse Foundation, |
| the Content is being redistributed by another party ("Redistributor") and |
| different terms and conditions may apply to your use of any object code in |
| the Content. Check the Redistributor’s license that was provided with the |
| Content. If no such license exists, contact the Redistributor. Unless |
| otherwise indicated below, the terms and conditions of the MIT License |
| still apply to any source code in the Content and such source code may be |
| obtained at <a href="http://www.eclipse.org" class="bare">http://www.eclipse.org</a>.</p> |
| </div> |
| </div> |
| </div> |
| </div> |
| <style> |
| /* Stylesheet for CodeRay to match GitHub theme | MIT License | http://foundation.zurb.com */ |
| pre.CodeRay{background:#f7f7f8} |
| .CodeRay .line-numbers{border-right:1px solid currentColor;opacity:.35;padding:0 .5em 0 0} |
| .CodeRay span.line-numbers{display:inline-block;margin-right:.75em} |
| .CodeRay .line-numbers strong{color:#000} |
| table.CodeRay{border-collapse:separate;border:0;margin-bottom:0;background:none} |
| table.CodeRay td{vertical-align:top;line-height:inherit} |
| table.CodeRay td.line-numbers{text-align:right} |
| table.CodeRay td.code{padding:0 0 0 .75em} |
| .CodeRay .debug{color:#fff !important;background:#000080 !important} |
| .CodeRay .annotation{color:#007} |
| .CodeRay .attribute-name{color:#000080} |
| .CodeRay .attribute-value{color:#700} |
| .CodeRay .binary{color:#509} |
| .CodeRay .comment{color:#998;font-style:italic} |
| .CodeRay .char{color:#04d} |
| .CodeRay .char .content{color:#04d} |
| .CodeRay .char .delimiter{color:#039} |
| .CodeRay .class{color:#458;font-weight:bold} |
| .CodeRay .complex{color:#a08} |
| .CodeRay .constant,.CodeRay .predefined-constant{color:#008080} |
| .CodeRay .color{color:#099} |
| .CodeRay .class-variable{color:#369} |
| .CodeRay .decorator{color:#b0b} |
| .CodeRay .definition{color:#099} |
| .CodeRay .delimiter{color:#000} |
| .CodeRay .doc{color:#970} |
| .CodeRay .doctype{color:#34b} |
| .CodeRay .doc-string{color:#d42} |
| .CodeRay .escape{color:#666} |
| .CodeRay .entity{color:#800} |
| .CodeRay .error{color:#808} |
| .CodeRay .exception{color:inherit} |
| .CodeRay .filename{color:#099} |
| .CodeRay .function{color:#900;font-weight:bold} |
| .CodeRay .global-variable{color:#008080} |
| .CodeRay .hex{color:#058} |
| .CodeRay .integer,.CodeRay .float{color:#099} |
| .CodeRay .include{color:#555} |
| .CodeRay .inline{color:#000} |
| .CodeRay .inline .inline{background:#ccc} |
| .CodeRay .inline .inline .inline{background:#bbb} |
| .CodeRay .inline .inline-delimiter{color:#d14} |
| .CodeRay .inline-delimiter{color:#d14} |
| .CodeRay .important{color:#555;font-weight:bold} |
| .CodeRay .interpreted{color:#b2b} |
| .CodeRay .instance-variable{color:#008080} |
| .CodeRay .label{color:#970} |
| .CodeRay .local-variable{color:#963} |
| .CodeRay .octal{color:#40e} |
| .CodeRay .predefined{color:#369} |
| .CodeRay .preprocessor{color:#579} |
| .CodeRay .pseudo-class{color:#555} |
| .CodeRay .directive{font-weight:bold} |
| .CodeRay .type{font-weight:bold} |
| .CodeRay .predefined-type{color:inherit} |
| .CodeRay .reserved,.CodeRay .keyword {color:#000;font-weight:bold} |
| .CodeRay .key{color:#808} |
| .CodeRay .key .delimiter{color:#606} |
| .CodeRay .key .char{color:#80f} |
| .CodeRay .value{color:#088} |
| .CodeRay .regexp .delimiter{color:#808} |
| .CodeRay .regexp .content{color:#808} |
| .CodeRay .regexp .modifier{color:#808} |
| .CodeRay .regexp .char{color:#d14} |
| .CodeRay .regexp .function{color:#404;font-weight:bold} |
| .CodeRay .string{color:#d20} |
| .CodeRay .string .string .string{background:#ffd0d0} |
| .CodeRay .string .content{color:#d14} |
| .CodeRay .string .char{color:#d14} |
| .CodeRay .string .delimiter{color:#d14} |
| .CodeRay .shell{color:#d14} |
| .CodeRay .shell .delimiter{color:#d14} |
| .CodeRay .symbol{color:#990073} |
| .CodeRay .symbol .content{color:#a60} |
| .CodeRay .symbol .delimiter{color:#630} |
| .CodeRay .tag{color:#008080} |
| .CodeRay .tag-special{color:#d70} |
| .CodeRay .variable{color:#036} |
| .CodeRay .insert{background:#afa} |
| .CodeRay .delete{background:#faa} |
| .CodeRay .change{color:#aaf;background:#007} |
| .CodeRay .head{color:#f8f;background:#505} |
| .CodeRay .insert .insert{color:#080} |
| .CodeRay .delete .delete{color:#800} |
| .CodeRay .change .change{color:#66f} |
| .CodeRay .head .head{color:#f4f} |
| </style> |
| <script type="text/x-mathjax-config"> |
| MathJax.Hub.Config({ |
| messageStyle: "none", |
| tex2jax: { |
| inlineMath: [["\\(", "\\)"]], |
| displayMath: [["\\[", "\\]"]], |
| ignoreClass: "nostem|nolatexmath" |
| }, |
| asciimath2jax: { |
| delimiters: [["\\$", "\\$"]], |
| ignoreClass: "nostem|noasciimath" |
| }, |
| TeX: { equationNumbers: { autoNumber: "none" } } |
| }) |
| MathJax.Hub.Register.StartupHook("AsciiMath Jax Ready", function () { |
| MathJax.InputJax.AsciiMath.postfilterHooks.Add(function (data, node) { |
| if ((node = data.script.parentNode) && (node = node.parentNode) && node.classList.contains('stemblock')) { |
| data.math.root.display = "block" |
| } |
| return data |
| }) |
| }) |
| </script> |
| <script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/MathJax.js?config=TeX-MML-AM_HTMLorMML"></script> |
| <!-- |
| Copyright (c) 2010, 2020 Contributors to the Eclipse Foundation |
| |
| See the NOTICE file(s) distributed with this work for additional |
| information regarding copyright ownership. |
| |
| This program and the accompanying materials are made available under the terms |
| of the MIT License which is available at https://opensource.org/licenses/MIT |
| |
| SPDX-License-Identifier: MIT |
| --> |
| |
| <div id="footer"> |
| <div id="footer-text"> |
| <a href="https://www.eclipse.org">Eclipse Home</a> |
| | |
| <a href="https://www.eclipse.org/legal/privacy.php">Privacy Policy</a> |
| | |
| <a href="https://www.eclipse.org/legal/termsofuse.php">Terms of Use</a> |
| | |
| <a href="https://www.eclipse.org/legal/copyright.php">Copyright Agent</a> |
| | |
| <a href="https://www.eclipse.org/legal">Eclipse Legal</a> |
| </div> |
| </div> |
| </body> |
| </html> |
