What is lower and upper multiplicity in autosar configuration element (module, container, parameter or reference). What does it mean in code. I mean if a parameter is has lower multiplicity = 1, and upper multiplicity=5, how is it reflected in code when generated?
Multiplicity means how many times this element (parameter or container) can exist.
If lower and upper multiplicity are equal, there must be exactly so many instances of the element. Most common with lower == upper == 1.
If lower and upper multiplicity are not equal, then there may be as few elements as the lower multiplicity, and as many as the upper. Most common with lower == 0 and upper == 1, which means the element can exist 0 or 1 times. That is, it's optional.
If the upper multiplicity is denoted with an asterisk (*), it means infinite. So an element with lower == 1 and upper == * must have at least one instance, and can have arbitrarily many.
Multiplicity is not directly reflected in the generated code, but the number of instances in a particular configuration is.
As a very common example, the multiplicity of ComSignal under ComConfig is 0 to *. So there may be no ComSignal containers at all, or there may be any number of them. The generated code will certainly have a signal ID in Com_Cfg.h for each ComSignal element, but the details of the generated code depend on the generator used.
As per Autosar Software Architecture, General Requirements on Basic Software Modules.
“Multiplicity” defines how many times an entity (in this case configuration
parameter) is instantiated.
The multiplicity of each configuration parameter has to be documented.
Description:
It shall be documented what determines the number of entries (e.g. “one per
frame”).
Additional Info not in the documentation:
1.Containers are named as such because containers contain Configuration parameters.
A container /sub container can refer to other container/sub container, now the reference can hold a multiplicity value, multiplicity then defines the possible number of instances of the contained parameters.
Ofcourse an example always is better illustrious than these words
Example:
Dcm module contains(when I say contains it actually means a sub container from here), DcmConfigSet(exists one config for one set of Dcm configuration), if you need multiple Dcm Configuration you could add many of them, One DcmConfigSet contains
(DcmDsd[1],DcmDsl[1],DcmDsp[0..1],DcmGeneral[1],DcmPageBufferCfg[1],DcmProcessingConditions[0....1])
This means for subcontainers having referenced as [1] has the same lower and upper multiplicity hence one instance of each subcontainer should be configured, whereas for DcmDsp,DcmProcessingConditions (you can have 0 instantiation "no need to configure" or can be configured based on your functional needs- higher multiplicity 1).
I really hope I can share you some code, but autosar code is not open source so I can't share it. Still I hope you understand the gist.
The reference link is General Software Architecture
Related
In the Vulkan spec it defines:
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT is equivalent to VK_PIPELINE_STAGE_ALL_COMMANDS_BIT with
VkAccessFlags set to 0 when specified in the second synchronization scope, but specifies no
stages in the first scope.
and similarly:
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT is equivalent to VK_PIPELINE_STAGE_ALL_COMMANDS_BIT with
VkAccessFlags set to 0 when specified in the first synchronization scope, but specifies no stages
in the second scope.
I'm unclear what it means by "with VkAccessFlags set to 0" in this context?
Technically VkAccessFlags is a type, not a variable, so it can't be set to anything.
(It seems to be adjusting the definitions of TOP/BOTTOM_OF_PIPE for some special property of VK_PIPELINE_STAGE_ALL_COMMANDS_BIT with respect to VkAccessFlags, but I can't quite see what that special property is or where it is specified.)
Anyone know what it's talking about?
(or, put another way: If we removed those two utterances of "with VkAccessFlags set to 0" from the spec, what would break?)
It is roundabout way to say the interpretation of the stage flag is different for a memory dependency.
For execution dependency in src it takes the stage bits you provide, and logically-earlier stages are included automatically. Similarly for dst, logically-later stages are included automatically.
But this applies only to the execution dependency. For a memory dependency, only the stage flags you provide count (and none are added automatically).
For example, let's say you have VK_PIPELINE_STAGE_ALL_COMMANDS_BIT + VK_ACCESS_MEMORY_WRITE_BIT in src. That means all memory writes from all previous commands will be made available. But if you have VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT + VK_ACCESS_MEMORY_WRITE_BIT in src, that means all memory writes from only BOTTOM_OF_PIPE stage are made available, so no memory writes are made available (because that particular stage doesn't make any).
Either way IMO, for code clarity it is better to always state all pipeline stages explicitly whenever one can.
Using pyiron, I want to calculate the mean square displacement of the ions in my system. How do I see the total displacement (i.e. not folded back by periodic boundary conditions) without dumping very frequently and checking when an atom passes over the boundary and gets wrapped?
Try to compare job['output/generic/unwrapped_positions'][-1] and job.structure.positions+job.output.total_displacements[-1]. If they deliver the same values, it's definitely fine both ways. If not, you can post the relevant lines in your notebook here.
I'd like to add a few comments to Jan's answer:
While job['output/generic/unwrapped_positions'] returns the unwrapped positions parsed from the output files, job.output.total_displacements returns the displacement of atoms calculated from each pair of consecutive snapshots. So if an atom moves more than half the box length in any direction, job.output.total_displacements will give wrong coordinates. Therefore, job['output/generic/unwrapped_positions'] is generally more trustworthy, but it is not available in all the codes (since some codes simply do not provide an output for unwrapped positions).
Moreover, if an interactive job is used, it is possible that job.structure.positions does not return the initial positions, i.e. job.structure.positions+job.output.total_displacements won't be initial positions + displacements.
So, in short, my answer to your question would be rather "Use job['output/generic/unwrapped_positions'] and if it's not available, use job.structure.positions+job.output.total_displacements but be aware of potential problems you might be running into."
I recently read that option-operand separation is a principle that was introduced in the Eiffel language (I've never used Eiffel).
From the Wikipedia article:
[Option–operand separation] states that an operation's arguments should contain only operands — understood as information necessary to its operation — and not options — understood as auxiliary information. Options are supposed to be set in separate operations.
Does this mean that a function should only contain "essential" arguments that are part of its functionality, and that there shouldn't be any arguments that change the functionality (which instead should be a separate function)?
Could someone explain it simply, preferably with pseudocode example(s)?
Yes, this is the idea: arguments should not be used to select particular behavior. Different methods (features in Eiffel terms) should be used instead.
Example. Suppose, there is a method that moves a 2-D figure to a given position. The position could be specified using either polar or Cartesian coordinates:
move (coordinate_1, coordinate_2: REAL_64; is_polar: BOOLEAN)
-- Move the figure to the position (coordinate_1, coordinate_2)
-- using polar system if is_polar is True, and Cartesian system otherwise.
According to the principle, it's better to define two functions:
cartesian_move (x, y: REAL_64)
-- Move the figure to the position with Cartesian coordinates (x, y).
polar_move (rho, phi: REAL_64)
-- Move the figure to the position with polar coordinates (rho, phi).
Although the principle seems to be universally applicable, some object-oriented languages does not provide sufficient means for that in certain cases. The obvious example are constructors that in many languages have the same name, so using options becomes the only choice (a workaround would be to use object factories in these cases).
I'm trying to implement the CiA 401(I/O). But I don't know how the device should behave if the object 6002 (input polarity) changes.
Should the value in object 6000 (read input) also change and if so, a PDO should also be sent, although nothing has changed at the physical input?
The only mandatory input polarity objects are 6002:0 and 6002:1, and it should affect the polarity of the corresponding digital on/off objects objects mapped at 6000. Note that DS-401 lists an "Entry Category" which dictates which objects and indices that are mandatory and which that are optional.
If you map the input polarity, it will be a RPDO in your application, and affect whatever TPDO that 6002 is mapped into. As far as I remember, the values inside 6000 should not change, only the values of the relevant TPDO. This TPDO will only be sent when it should - that is, depending on how it is configured: cyclic, on change, on request etc.
For verifications (with ispin) that use never claims, I get outputs with depth reached larger than the number of states and the number of transitions, e.g.:
Full statespace search for:
never claim + (REQ5)
assertion violations + (if within scope of claim)
cycle checks - (disabled by -DSAFETY)
invalid end states - (disabled by never claim)
State-vector 60 byte, depth reached 87, errors: 1
41 states, stored
10 states, matched
51 transitions (= stored+matched)
9 atomic steps
hash conflicts: 0 (resolved)
I find that a bit unintuitive. Is there a precise description of the semantics of "depth reached" somewhere (more thorough than pan's output format description)? Maybe the meaning of
longest depth-first search path contained 87 transitions
does not refer to the 51 transitions, but to the transitions of the system automata composed with the never claim?
Yes, you are (kind of) right when you say it refer to the transitions of the system automaton composed with the never claim. Yet in the same time it is the length of the path in the system being verified, because one step of system composed with never claim is exactly one step of the system. Of course depending on never claim one might need to explore more or less transition than system has. Paths are not even necessary loop free (depending on the claim) and even not minimal (unless special option is set).