Anonymize names

This CIF to CIF transformation anonymizes the names of all named objects in the CIF specification.

Anonymization can be useful when the model is to be shared publicly, but contains confidential information. For instance, this can be useful when adding a confidential model to a bug report, when contributing it to model repositories, or when it is a part of a publication or thesis.

Only the names of named objects are anonymized. The resulting specification may still contain string literals, references to file names, etc, that are not anonymized by this transformation. It remains your own responsibility to decide whether or anonymizing names is sufficient to allow a model to be made public or not.

Supported specifications

This transformation supports a subset of CIF specifications. The following restrictions apply:

  • Automaton to string casts are not supported.

Preprocessing

No preprocessing is currently performed by this CIF to CIF transformation.

Implementation details

The new names of objects are based on a fixed prefix that depends on what kind of object it is, followed by a number. The following table indicates the prefixes that are used for the different kinds of objects:

Prefix Kind of object

alg

Algebraic variable

aparam

Algebraic parameter of a component definition

aut

Automaton

autdef

Automaton definition

const

Constant

cparam

Component parameter of a component definition

disc

Discrete variable

enum

Enumeration

eparam

Event parameter of a component definition

evt

Event

field

Field of a tuple type

fparam

Parameter of a user-defined function

func

User-defined function

fvar

Variable in an internal user-defined function

grp

Group

grpdef

Group definition

input

Input variable

inv

State (exclusion) invariants and state/event exclusion invariants

inst

Component instantiation

lit

Enumeration literal

loc

Location of an automaton

lparam

Location parameter of a component definition

type

Type declaration

For most kinds of objects, each unique object of that kind gets a unique number as postfix. For instance, consider a specification with algebraic variables and constants:

group g:
  alg bool at = true;
  alg bool af = false;
  const bool ct = true;
  const bool cf = false;
end

alg bool at = true;
alg bool af = false;
const bool ct = true;
const bool cf = false;

The result of anonymizing the names would be:

group grp1:
  alg bool alg1 = true;
  alg bool alg2 = false;
  const bool const1 = true;
  const bool const2 = false;
end

alg bool alg3 = true;
alg bool alg4 = false;
const bool const3 = true;
const bool const4 = false;

The four algrebraic variables each get a different number as postfix, as do the constants. This makes it easy to find a specific named object based on its name. But algebraic variables and constants are numbered independently.

For controllable and uncontrollable events, the new name is additionally prefixed with c_ and u_, respectively. Events that are not controllable or uncontrollable don’t get an additional prefix.

Compatible enumerations have the same number of literals, and the same literal names in the same order. The new literal names for compatible enumerations will be identical, to ensure they remain compatible.

To ensure that compatible tuple types remain compatible, their field names are not numbered globally, but are instead based on their index within the tuple type. That is, for a tuple type tuple(int nr; real weight) the anonymized result is tuple(int field1; real field2).

Objects without a name, such as nameless locations or nameless invariants, are not given a name.

Renaming

Renaming is performed as explained in the previous section.

Size considerations

The only change to the specification is that objects are renamed. The new names could be shorter or longer than the original names.

Optimality

n/a

Annotations

This transformation does not process, add, or remove any annotations. The names of annotations and annotation arguments are not anonymized.