Issue 10642: Timing diagrams (sysml-rtf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Revision Severity: Critical Summary: Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines. Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: February 5, 2007: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Much useful discussion about the usefulness of timing diagrams occurred within the RTF. Their addition could be considered in future versions of SysML. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 05 Feb 2007 00:08:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Tim Weilkiens Company: oose Innovative Informatik GmbH mailFrom: tim.weilkiens@oose.de Notification: Yes Specification: OMG SysML Specification Section: Timing diagrams FormalNumber: ptc/06-05-04 Version: 1.0 RevisionDate: 04/05/06 Page: none Nature: Revision Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Description o, > for example, if we look at Fig. B-8 in the current SysML spec timing diagram may be used to represent a possible > scenario of state and/or conditions changing in time. For example: > Here the scenario begins by starting the vehicle, > accelerating, braking two times, the first time up to > certain speed and the second time up to stop completely. Wasn't following your comments above about scenarios. > I guess that timing diagrams should be only illustrated in > the Interaction chapter (further examples may be defined > for Activity diagrams with a more careful understanding of > the underlying semantics). This would be consistent with the use of ibd's for activities being in the activity chapter. Requires a new timing example not based on activities. Do you have one? Need it by tomorrow, I think, due to the short discussion period. >ame > for duration observations). > 4. Time observations could be used also in Activity > Diagrams, although there are no examples in the UML spec. > Thus, in the Activities chapter a richer example to specify > constraints could be ao3dded. I . It would be useful to illustrate UML TimeObservations to se to include examples > of notation to attach TimeConstraint, DurationConstraint, > TimeObservation, DurationObservation in activity diagrams. > To my understanding, UML proposes a notation for these > concepts for all behaviour diagrams, but it shows examples > in sequence diagrams only. The notation would consist just li > in adding the > construct time expressions, which is a very powerful > specification mechanism. In the previous example, I defined ti > two time observations t1 and t2, and in this way many time > constraints may be built with this rios Subject: RE: update of draft Ballot 4, Issues 11654 & 10642 (Timing Diagrams) Date: Wed, 7 Mriosay 2008 15:53:19 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: update of draft Ballot 4, Issues 11654 & 10642 (Timing Diagrams) Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gAAyZmCAAEgOSsAAN1YMgAAETTvAAAeOwsAACKXTgACZFIAAAB2VHMA== From: "ESPINOZA Huascar 218344" To: "Friedenthal, Sanford" , "Burkhart Roger M" , Cc: X-OriginalArrivalTime: 07 ay 2008 13:53:20.0359 (UTC) FILETIME=[B5764F70:01C8B049] Hi again, Timing diagrams! Issue 10642 proposes defer. I guess that we could provide a .resolve. resolution together with 11654 by keeping the scope of the resolution to the existing UML Simple Time Model. I mean, future SysML specs could face with continuous time, logical time, etc. Moreover, as Sandy pointed out, both issues (10642 & 11654) would go better if merged. Some comments on the current 11654 resolution (thanks also to Charles Andre who provided some inputs): 1. The more important drawback of this proposal is that the example uses the vertical axis to represent .actions.. In this way, one of the consequences is that timing diagrams would tend to be semantically incorrect. More concretely: look at the .Key off. action: it can occur at the same time instant when .Driving. is occurring! Note that the horizontal axis is always .time.. We should keep the vertical axis to represent .States or Conditions. as defined in the UML spec. Please see below fig. 14-29 from the UML-Superstructure: 2. Timing diagrams are better to support .scenarios.. So, for example, if we look at Fig. B-8 in the current SysML spec. A timing diagram may be used to represent a possible scenario of state and/or conditions changing in time. For example: Here the scenario begins by starting the vehicle, accelerating, braking two times, the first time up to certain speed and the second time up to stop completely. I guess that timing diagrams should be only illustrated in the Interaction chapter (further examples may be defined for Activity diagrams with a more careful understanding of the underlying semantics). 3. It would be useful to illustrate UML TimeObservations to construct time expressions, which is a very powerful specification mechanism. In the previous example, I defined two time observations t1 and t2, and in this way many time constraints may be built with this .timing marks. (the same for duration observations). 4. Time observations could be used also in Activity Diagrams, although there are no examples in the UML spec. Thus, in the Activities chapter a richer example to specify constraints could be added. I.d propose to include examples of notation to attach TimeConstraint, DurationConstraint, TimeObservation, DurationObservation in activity diagrams. To my understanding, UML proposes a notation for these concepts for all behaviour diagrams, but it shows examples in sequence diagrams only. The notation would consist just in adding the .lines. in the border of Actions (or others) as shown below: 5. Looking at time constraints in the issue resolution, they have not the brackets .{}.. This should be aligned to UML, I think. Please let me know you point of view about these five points. Best regards, Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 6 mai 2008 14:25 À : Burkhart Roger M; sysml-rtf@omg.org Objet : RE: update of draft Ballot 4 Roger Relative to the scope issue for the timing diagrams, I suggest we hear back from other vendors for thier input as well as others. I Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, Ma 06, 2008 1:44 AM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: update of draft Ballot 4 Sandy-- In reply to your comments below: I've corrected the Disposition line in Issue 12157 to read Resolved. Thanks for the catch. Issues 11653, 11627 (and 11117 which you suggest could be associated), 10642, 10539, 10472, and 10073 all have resolutions of Deferred. I've given a Deferred resolution to all issues for which I've received no proposed resolutions to date, but which were received before the RTF Issue deadline of January 1, 2008 (later issues will be automatically deferred). Any Discussion notes on Deferred issues are only a brief summary which is by no means complete or authoritative, since their whole point is that more work is required to develop a resolution. While more discussion could always be added to a Deferred issue, the point of the resolution is that sufficient work was not completed to resolve the issue and that further work should continue a follow-on revision. Since the whole point of Deferred resolutions is that a more complete resolution was not developed by the cutoff date for the current RTF, I don't see a need for adding more to these resolutions (such as links to other issues) prior to voting. All further work can be continued by the task force responsible for the next revision. On Issue 10342, I'll leave any response to your comment on Issue 10342 to Eldad Palachi, who prepared the initial draft of this resolution. > The following statmenet does not appear to be correct since item flows are directed relationships and are not typed "Item Flows CAN be typed by any classifier as written in the second paragraph of section 9.3.2.6. Thanks for calling attention to the significant change in Issue 11654, to add a timing diagram to SysML to support timelines as referenced by Chapter 11 Activities. Do you think this scope of change should be considered within a revision update of the SysML 1.0 spec? --Roger -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, May 05, 2008 5:37 PM rder of Actions (or others) > as shown below: Will look at this, but we have short discussion period this time to update the resolution. As you point out, the time model is UML is very lightly explained, and I don't really understand it. Can you provide the above material? Need it by tomorrow. > s should be aligned to > UML, I think. Yes, thanks. Conrad5. Looking at time constraints in the issue resolution, {}{} > they have not the brackets To: Burkhart Roger M; sysml-rtf@omg.org Subject: RE: update of draft Ballot 4 Roger Comments on Draft Ballot 4 Issue 12157 The last statement in the resolution says "Closed, no change". This should say "Resolved" Issue 11654 This issue adds a UML timing diagram to SysML. It also enables a timing diagram representation for an activity diagram. This is a significant change and attention should be called to this proposed resolution. Issue 11653 The discussion should be elaborated to refer to the comment below in Annex A, and possibly include a resolution that proposes a change to the reference to the formal BNF. I suggest a change to the following on pg 176: FROM SysML diagrams including the enhancements described in this section is intended to conform to the Diagram Interchange Standard to facilitate exchange of diagram and layout information. A more formal BNF has been introduced in selected chapters to facilitate diagram interchange, which is referred to in the Language Formalism chapter. TO SysML diagrams including the enhancements described in this section are intended to conform to the Diagram Interchange Standard to facilitate exchange of diagram and layout information. [Deleted 2nd sentence] Issue 11627 This can be associated with issue 11117 by Eldad Pelachi regarding sending data via a message on a sequence diagram. A similar issue has been raised by M. chonoles with the need to enable sequence diagrams to be used with flowports. I would suggest tieing these issues together. Issue 10642 This should refer to proposed resolution for Issue 11654 which does add timing diagrams. Tie these two issues together. Issue 10539 I think this issue is resolved by the proposed resolution to issue 11501 Issue 10472 Suggest adding the statment on applicability of instance semantics and not deferring this. I think this will provide needed clarification. We can address broader issues related to instance semantics in future revisions. Issue 10342 The following statmenet does not appear to be correct since item flows are directed relationships and are not typed "Item Flows CAN be typed by any classifier as written in the second paragraph of section 9.3.2.6. Issue 10073 Seems like this is a duplicate issue (need for templates in SysML) but I did not check to confirm Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 11:13 AM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4. Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Subject: RE: update of draft Ballot 4, Issues 11654 & 10642 (Timing Diagrams) Date: Fri, 9 May 2008 14:00:55 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update of draft Ballot 4, Issues 11654 & 10642 (Timing Diagrams) Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gAAyZmCAAEgOSsAAN1YMgAAETTvAAAeOwsAACKXTgACZFIAAAB2VHMAA5GmDgACorleA= From: "ESPINOZA Huascar 218344" To: , "Friedenthal, Sanford" , "Burkhart Roger M" , Cc: X-OriginalArrivalTime: 09 May 2008 12:00:56.0806 (UTC) FILETIME=[56D14860:01C8B1CC] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m49C4H4r020932 Hi Conrad, all, I have the figures attached in my previous email on Timing Diagram, but I didn't work the explanatory text. I think that I will not able to finish it correctly today. In general, I'd prefer to defer both issues in Timing Diagrams, as far as the proposed use (actions in the vertical axis) in the resolution would require some discussion. However, I can still provide the required example the next week. Kind regards, Huascar -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : jeudi 8 mai 2008 20:02 À : ESPINOZA Huascar 218344; 'Friedenthal, Sanford'; 'Burkhart Roger M'; sysml-rtf@omg.org Cc : charles.andre@unice.fr Objet : RE: update of draft Ballot 4, Issues 11654 & 10642 (Timing Diagrams) Huascar, > Some comments on the current 11654 resolution (thanks also > to Charles Andre who provided some inputs): > 1t's the primary point of the occurrin, this is the semantics of the activity being represented, which is in Figure 11.10. It might not be entirely realistic, but it's consistent. Having more realistic examples would be a separate issue. defined in the UML spec. Please see below > fig. 14-29 from the UML-Superstructure: Yes, and it still does. In this usage, the conditions refer to the values of the properties corresponding to the actions. > 2. Timing diagrams are better to support sc > We should keep the vertical axis to represent !tes or > Conditions Note that the horizontal axis istitiSt always > ssue. ving n: it can occur at the same time instant whenDr > > In this way, one of the consequences is that timing diagrams would > tend to be semantically incorrect. More concretely: look at theKe ff > . ns