RealTime-at-Work

The short answer is that there is no unique conceptual model for systems engineering. But there are several ones that will be listed hereafter!

Before going further, a conceptual model is at core of Model-based Systems Engineering (MBSE). MBSE shall integrate different views or domains (CAD, CAM, thermal, …) of the same systems in a coherent and consistent way. Thus the document-centric approach is replaced by a model-centric one. It is crucial for the development of systems such as in mechatronic as it is hard to develop different domains independently.

SysML is a model you must know, especially if you are reading us. But SysML is said to be quite generic by industrial practitioners, probably too much. Indeed domain-specific engineers have a hard time to adapt vocabulary and learn how to use SysML in their daily-job. More specific Domain Specific Languages (DSL) would be preferred! SysML is normalised by the OMG.

AP233 is a data model targeted at the exchange of systems engineering data between diverse tools. It could be considered as a neutral file format exchange but could also be used as a foundation for a CASE tool. It is an application module of the ISO 10303. The ISO10303-233 is not yet finalized

The OMG SE DSIG working group, INCOSE and the AP233 development team are working together to align them.

The AFIS, French chapter of the INCOSE, has also worked on writing such a model. The second version of the Modèle de données was written in 2005.

MODAF and DoDAF are architecture framework. UPDM unified them as a UML profile. Due to its profile nature it may not be an answer compared to a DSL. Anyway the model behind the profile is worth considering.

Finally browsing the web for information or conceptual models, you could find other proposals especially in the research literature such as this thesis by J. J. Simpson. This thesis propose a meta-model inspired by existing standards altogether with a process called CCFRAT.

Regarding links to domain specific models (CAD, CAM, PDM,…), AP233 might well be the only answer. Indeed AP233 is one of many application modules all written in the same specification language (ISO EXPRESS language). They all build on the product_view concept. Different views could well share the same properties (for instance weight or outer_width). Other models do not prescribe or provide a way to synchronize with other domain specific models.

Despite MBSE being a hot topic — INCOSE 2020 vision insists on it —, very few tools provide an integrated database or are able to connect to one. And you? On which standard/format do you invest or bet on? Does your company have a plan about this issue? Do you think it is possible to solve models integration and consistency in your domain? Leave a comment to tell us more.

Tags: sysml // 1 Comment »

One popular complain about SysML is that the model does not look like the thing you are building (designing). But it is not a fatality! Indeed, Ahsan Qamar has reviewed literature and demonstrated how to keep synchronized SysML with CAD, electrical,… models in his licentiate thesis.

Moreover the SysML specification 1.2 on section 8.3.1.1 (page 36) say:
SysML allows blocks to have multiple compartments, each optionally identified with its own compartment name. [...]. Some standard compartments are defined by SysML itself, and others can be defined by the user using tool-specific facilities

Thus a tool could display a compartment showing (externally synchronized) visual design as in the following diagram. Maybe we could differentiate between a sketch that would be drawn in the concept compartment, and the real design that would be drawn in the preview compartment. The former would be replaced by the second on project progress.

Please do comment this idea in the discussion area bellow.

PS: contact me to work towards making it real.

SysML preview/concept compartment proposal

Tags: sysml // 6 Comments »

RTaW-ECU is a tool that optimizes the scheduling of tasks so as to reduce the load peaks while meeting task deadline constraints. Precisely, RTaW-ECU allows to schedule on a ECU (Electronic Control Unit) large sets of elementary software modules – usually called “services” in the aerospace or “runnables” in the automotive field, the latter term will be used in the following – in a context where there are hundreds of software modules and only a few OS tasks are allowed. For this reason, runnables must be grouped together and scheduled within one or several “sequencer” tasks. RTaW-ECU provides several algorithms to build and configure sequencer tasks in such a way as to uniformly balance the load over time while meeting runnable deadline constraint, be it on mono-core and multi-core platforms. Interested in more information and experiments? Please refer to this paper or the following slides.

RTaW-ECU is available for Windows (32 and 64 bits) and Linux (32 and 64 bits) and free for all uses, more information on the software web page. Free support is available through a forum. For companies requiring guaranteed results, RTaW is offering professional support package, customized developments, training and R&D services.

Tags: software, talks at conferences // Add Comment »

Here is the presentation given at the first Topcased days on 4th February. It first presents fUML and what it adds to MBSE, namely semantic verification. Then the second part of the talk is about how hard it is to develop such a plugin for the Topcased editor.

I received only one question and one remark during the questions time. The question was: Do you think that fUML can simplified the plugin development?. I think the person misunderstood my presentation here and thought that I was trying to apply fUML to the plugin development. To his defence, I was the only one who talked about the troubles of programming for Topcased. I thought it was recommended by the committee… The remarks was made by Pierre Gaufillet saying that I tried much advanced stuff than them!

Tags: Eclipse, sysml // 1 Comment »

From now on NETCAR-Analyzer timing verification software is free for all uses and available for download from RTaW website.

NETCAR-Analyzer helps the system designer optimize the scheduling of frames on Controller Area Network (CAN) and check that the requirements on transmission delays are met. NETCAR-Analyzer implements a set of proprietary configuration algorithms that enable increasing the bus load, reaching 60% and above in real applications – with hard real-time guarantees. NETCAR-Analyzer has been developed by RTaW, INRIA and INPL and has been in use in the industry since 2006. NETCAR-Analyzer is a great complement to RTaW-Sim, our free CAN network simulator with fault-injection capabilities.

NETCAR-Analyzer is available for Windows (all versions – 32 and 64 bits), more information on the software web page. Free support is available through a forum. For companies requiring guaranteed results and all advanced features of NETCAR-Analyzer, RTaW is offering professional support package, customized developments, training and R&D services. RTaW is committed to providing the highest level of services for the products it develops.

Tags: software // Add Comment »

TIMMO-2-USE stands for “Timing Models – Tools, algorithms, languages, methodology” which is a good summary of the objectives of the project: the development of novel tools, verification algorithms, description languages, and a methodology validated by use cases in order to dimension and validate automotive embedded systems, that are becoming extremely complex with an increasing number of safety-critical functions.

TIMMO-2-USE, started in October 2010 for a duration of 2 years, involves 17 partners from France, Germany, and Sweden including larger companies such as Volvo, Continental, Robert Bosch and Delphi but also research institutes (e.g., Inria, T.U. Braunschsweig, Mälardalen University) and smaller tool vendors such as RTaW. The list of all partners is available on TIMMO-2-USE web site. The outcomes of the project are reviewed by an advisory board of car manufacturers made up of Volvo, PSA, Volkswagen, Audi and Daimler in order to facilitate their dissemination in the industry.

In TIMMO-2-USE, RTaW is the leader of the work-package “Algorithms and tools” and, in collaboration with its partners, will strive to come up with efficient methods and tools suited to design next generation automotive systems in a cost and time effective manner. TIMMO-2-USE, along with the aerospace PEGASE project, enables RTaW to strengthen its R&D services and software offer for the design of complex safety-critical systems.

Interested in more information? please contact jorn.migge@realtimeatwork.com, cell: +39.36.65.25.07.66..

Tags: Uncategorized // Add Comment »

Solution-space exploration is one of the SE activities that is not always traced. It is frequent that the requirement document only contains the final choice. Today, I will present how to express alternatives in requirements.

«containment» is not a solution!

Before showing you how to do it, I must say again that «containment» is only a structural link. If you really want to use it, you won’t be able to express alternatives. Indeed all sub-requirements won’t be different than the others.

«refine» links to express alternatives

In previous post, I show you how you can derive new requirements by using the «refine» link. I stress you on using it with several sources (aka “clients”) to express the conjunction of the sub-requirements (just like the left «refine» of the following diagram). Solution-space exploration is just a synonym for refinement disjunctions.

Following figure shows that requirement R1 could be derived either by satisfying S1.R1 and S1.R2, or by satisfying S2.R1. That’s it! Simple but with clear semantic…

Alternative requirements for a traffic lights.

conclusion

You know now how to express semantically richer relationships between requirements. Later, it will allow you to automatically check links between refinements. Lamsweerde et al [1] also propose this in KAOS/GORE methodology.

In future posts, I will introduce you on how to use formal requirements directly in the model. The other things I will talk about later are obstacles. Obstacles are what made an alternative not viable or not good enough.

How about you? Do you express requirements alternatives in your SysML models? Let us know in the comments what is your way of modelling.

Further reading:

• [1] Requirements Engineering, from System Goals to UML Models to Software specifications, Axel van Lamsweerde

Tags: sysml // 2 Comments »

SysML is at the center peace of MBSE. But many questions are raised when it comes to use it really. Most of them are related to requirement. Today, I will focus on how to link derived requirements.

I hear you say: Easy, use the «deriveReqt»!. But I think that using a «deriveReqt» is not the best way to link derived requirements. Let us see why on the house heater example.

The top goal of the heater system is to keep the house warm enough for the house’s temperature to be in the comfortable temperature range of every inhabitants of the house. It could be more formally define with the following OCL+Temporal logic formula:
always(theHouse.inhabitants->forAll(p | p.isIn(theHouse) implies p.conformtableTemperatureRange.contains(theHouse.temperature)))

This goal express exactly what the system should achieve. The system might set the temperature to zero if there is no (present) inhabitant or keep the temperature constant. Now we can derive this goal to a more concrete one. For instance, always(theHouse.temperature = 19°C). The rationale is that you make the hypothesis that 19°C is comfortable for everyone. You would express this in the SysML model with an OCL invariant or a parametric constraint on Person (self.comfortableTemperatureRange.contains(19°C)). The context model is thus as on following diagram.

Heater system BDD

For traceability reason, you would like to link the high level requirement, the low-level one and the invariant. But you cannot use the «deriveReqt» as it can only link requirements. Hopefully «Refine» can link with other model elements! Moreover in the formal method background, refinement has been well studied. Of course, it comes with several definitions (forward/backward-refinement, logical implication, bisimulation, …) but at least you can pick one.

Refinement of requirements for a heater system

Additionally a tool (to be written) can now formally check the refinement. I know SysML is not formal but ideas from fUML (aka Executable UML) can be applied for that. This is exactly what people from the KAOS/GORE method express and push forward. On the previous example the logical implication can indeed be automatically verified, because the conjunction of the invariant and the low-level formula implies the high-level one.

There are additional advantages, such as expressing alternative derived requirements, that I will demonstrate on future post. In conclusion, you can of course use the «deriveReqt» but then your tool shall enforce the presence of a rationale, or use the «Refine» when the rationale is already in the model and formally provable.

Edit: I forgot to mention Containment link! Containment link is related to model organisation and has no meaning (semantic) per se. Or you consider the extension set as in the property based requirement… but in that case you won’t be able to form a semi-lattice! More in future post.

Further reading:

• Requirements Engineering, from System Goals to UML Models to Software specifications, Axel van Lamsweerde
• Toward a property based requirements theory: System requirements structured as a semilattice, Patrice Micouin, Systems Engineering, Volume 11, Issue 3, pages 235–245, Autumn (Fall) 2008
• KAOS on wikipedia
• Program refinement on wikipedia
• Temporal Extensions of OCL Revisited, Michael Soden and Hajo Eichler, ECMDA-FA ’09: Proceedings of the 5th European Conference on Model Driven Architecture – Foundations and Applications
• B Method
• TLA+

Tags: sysml // Add Comment »

RTaW is pleased to announce a new release of RTaW-Sim, our free CAN network simulator. Highlights of this 1.1.0 version:

• possibility to launch RTaW-sim from command line which makes it possible to run simulations from another software such as a spreadsheet,
• many improvements: random seeds can be chosen by the user, bus load indicator, simulation speed measured in events per second, etc
• better documentation.

As always RTaW Sim is available for Linux (32 and 64 bits) and Windows (all versions), direct download links are here or please refer to this post for more detailed information.

Tags: software // Add Comment »

Tags: sysml // Add Comment »