Points
The main data type of the ECU simulation is the vspyx.Runtime.Point
. It describes the single instance – the single event of something that happens and is understood to be a new layer of the communication. For instance, if a signal is decoded from a PDU, a vspyx.Communication.ISignalPoint
will be created.
This Signal Point would then carry the Internal Value it decodes to, which would be the value of this reception of the Signal on the wire.
It would also carry the Physical Value – the transformed value. So, for a Coolant Temperature you may have an Internal Value of 140. If the transformation for the signal says the Physical Value in degrees Fahrenheit is y=2x-40, the Physical Value would be 50 degrees Fahrenheit.
The PDU that the Signal Point was created from would have been a vspyx.Communication.PDUPoint
. These Points reference their Traceable, so we can know that they are all instances of the same abstract PDU or Signal respectively.
Points are directional, they can have a direction of either Transmit or Receive. This signals to the PointProcessors whether we want to turn, for instance, an IPDatagramPoint into an EthernetDataLinkPDUPoint for transmit or a UDPDatagramPoint for receive.
Since Points are a subclass of vspyx.Core.Linkable
, they leverage that to have other Points as their parents and children, these can also be accessed as upstream and downstream Points. Further decodings of Points abstracting away from the Network Event are always linked as children, so a UDPDatagramPoint would always be a child of an IPDatagramPoint. However, depending on whether the Point has a direction of Transmit or Receive, that UDPDatagramPoint would either be considered to be in the collection of upstream or downstream Points respectively.
The parenting relationship of Point allows us to analyze and display which Points were used in the creation of the Point you’re looking at. An IPDatagramPoint may have been created from two IP fragments, which are EthernetDataLinkPDUPoints here. We allow you to start at the IPDatagramPoint and trace back to however many EthernetDataLinkPDUPoints created it.
There is also a concept within Point called IsDoneBeingConsumed. This is a mutability flag for the downstream relationships of the Point. Consider that an EthernetDataLinkPDUPoint is the first fragment of an IP datagram. We would want to hold the EthernetDataLinkPDUPoint in a PointProcessor which was reassembling the fragments and creating IPDatagramPoints. However, we don’t want to withold the Point from the rest of the Environment.
Once we have applied all of the initial processing we can do for a Point at the time we receive it, we dispatch it to the Environment. The IsDoneBeingConsumed flag will be become true once no PointProcessors are holding a reference to the Point, hoping to use it as an upstream Point for something more. Once it becomes true, it will never become false again, and you can know that the upstream/downstream relationships of that Point will not change any further.