IES {selector,synchronous} Request (INTEGER{time(0), day(1), date(2)} DEFAULT 0) Confirm (CHOICE{[0]Time, [1]DayInWeek, [2]Date}) Time::=SEQUENCE{hour INTEGER SIZE (0..24), ".", minute INTEGER SIZE (0..60) OPTIONAL) DayInWeek::=IA5String{"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"} Date::=SEQUENCE{Month, "/", DayInMonth} Month::=IA5String{"January", "February" "December"} DayInMonth::=INTEGER SIZE (1..31) Refuse (cause INTEGER{watchBroken(0), noWatch(1)) Fig. 7.36 Operation properties are declared in the operation specification Three additional, optional properties are listed in Fig. 7.22: time constraints, activity time and user-defined properties. The time constraint property defines when in time the operation shall be per- formed. For example, certain heavy maintenance tasks should be done at night, when the system load is lower. Note that a time constraint does not restrict when an operation request can be initiated, only when the corresponding activity shall be started. The time when an operation can be performed is specified as a temporal expression, using absolute time, repeating time intervals and relation to the time of a previous operation. An example of a temporal expression in the operation specifi- cation for sellWatch could be: More than 7 days have elapsed since last sellWatch and absolute time is not Sunday and absolute time is not less than 9 am and absolute time is not more than 5 pm. The activity time property defines the maximum time expected for the activity to execute. Note that this is not the same as total delay between an initiated Request and a detected Confirm or Refuse, since one has to add time for state handling (=checking preconditions and setting postconditions), for message processing and for message transport, in order to get the total delay. Activity time can be specified in either of three forms: Absolute form, e.g. as 100 ms. A second alternative is a user-defined symbolic timer value, e.g. PRST (Power Ringing Supervision Time). A third alterna