<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hello gents,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">pardon my intromission, but I see the INCOSE Systems Engineering Handbook as a domain agnostic reference/guideline, and in that sense would see reasonable that text distinguishes between "state" and "mode" even if not providing a definitive definition for each. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thus, leaving the user to define those terms for the particular /application/domain/system they are working on.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I could see a situation where a system has different operating <b>modes </b>(nominal, degraded, power-off, etc.) and each of these modes includes different internal <b>states. </b></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Cheers</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Paulo</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><b><br></b></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, May 22, 2026 at 10:19 AM Prof. Dr. Peter Bernard Ladkin <<a href="mailto:ladkin@causalis.com">ladkin@causalis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2026-05-22 01:27 , Les Chambers wrote:<br>
><br>
> In these contexts, synonyms abominate the functional Safety countryside. They must be hunted down <br>
> and eliminated with extreme prejudice - along with the “qualitative state machine(s)” they rode in <br>
> on.<br>
><br>
First, it seems silly to me to renounce synonyms. In the 61508 context, it would be ridiculous to <br>
insist people say/write Equipment Under Control when they can write EUC and even more ridiculous to <br>
insist they say/write Equipment Under Control Control System when they can say/write EUCCS.<br>
<br>
Second, you seem to have a prejudice for working with numbers when it comes to state machines. <br>
That's fine, I guess, as a personal preference. But if you perform any system development using <br>
formal methods (which 61508 now says is "highly recommended" for any safety function) you will very <br>
quickly have to get used to manipulating state machines which work on symbols which are not numbers. <br>
For almost all formal verification techniques for the last 57 years use them or some equivalent.<br>
<br>
PBL<br>
<br>
Prof. Dr. Peter Bernard Ladkin<br>
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany<br>
Tel: +49 (0)521 3 29 31 00<br>
<br>
_______________________________________________<br>
The System Safety Mailing List<br>
<a href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" target="_blank">systemsafety@TechFak.Uni-Bielefeld.DE</a><br>
Manage your subscription: <a href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" rel="noreferrer" target="_blank">https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a></blockquote></div>