mw_com_fmea#

Failure Modes#

LoLa#

Communication.AnyFunctionBlocksLongerThanExpected#: Any API of mw::com (LoLa) blocks longer than expected (or indefinite)

Communication.InMemoryConfigurationWrong#: The in-memory (cpp representation) does not match the on file-system JSON configuration.

Communication.FunctionCalledFromMultipleThreads#: Any API is called within multiple threads concurrently without any further synchronization.

Communication.GeneratedCodeDoesNotMatchGenerationInputs#: Proxys and Skeletons as data-types are generated using the aragen and not handwritten, may not match to the input (Meta-Model).

Communication.MisusedApis#: APIs are invoked in either an invalid context or non public APIs are invoked.

Skeleton#

Creation#

Communication.CreationOfSkeletonNotPossible#: It is not possible to create a skeleton instance

OfferAService#

Communication.ServiceOfferedWithoutInitialFieldValue#: A service is offered, although at least one of its field has no initial value set by the provider.

Communication.ServiceNotOffered#: A skeleton service is offering a service, but the service is silently not offered. Note: offered in this case means, that it is also connectable

Communication.ServiceOfferedOnWrongBinding#: A skeleton is offering a service on the wrong binding. Meaning, the service is not offered on the intended binding, but on an unintended one.

Communication.ServiceOfferedUnderWrongIds#: A skeleton is offering a service with wrong identifiers. This can include a service id, a instance id or also the service version.

Communication.OffersAlreadyOfferedService#: A skeleton offers a service that was already offered. Either by another process or by itself.

Communication.ServiceOnlyPartiallyOffered#: A skeleton offers a service, which is not visible to all consumers, but only to parts of them.

StopOfferAService#

Communication.ServiceOfferingNotStopped#: A skeleton offered a service, but the stop offering did not work.

Communication.ServiceOnlyPartiallyStopOffered#: A skeleton stop offers a service, but the service is still seen a partial set of consumers.

Communication.ServiceStopOfferedOnWrongBinding#: A skeleton is stop offering a service on the wrong binding. Meaning, the service is still offered on the actual binding.

Communication.ServiceStopOfferingWrongIds#: A skeleton is stop offering a service under wrong IDs. This can include a service id, a instance id or also the service version.

AllocateAnEventOrField#

Communication.MemoryAllocatedInWrongSection#: The memory for an event is allocated in the wrong memory section (e.g. in Heap, another Shared Memory segment or the stack).

Communication.TooFewMemoryAllocated#: The event allocation allocates too few memory (including no memory at all).

Communication.WronglyAlignedMemoryAllocated#: The memory for an event/field is allocated in a wrongly aligned manner.

Communication.TooMuchMemoryAllocated#: There is too much memory allocated for one event/field

Communication.AllocatesAlreadyAllocatedMemory#: The memory for an event/field is allocated from already allocated memory (not free memory).

SendAnEventOrField#

Communication.SendingEventChangesUserData#: A call to send manipulates the data that was provided by the caller.

Communication.SendingAnEventOrFieldSendsDataOnlyPartially#: Data that is send by the user, only reaches partially the consumer. This can happen in two ways, only a partial number of consumers see the data or all consumers see only partial data.

Communication.SendingEventOnlyPartiallyNotifiesConsumer#: When data is sent, consumers that have a callback registered, are only partially notified.

Communication.SendingEventSendsToWrongConsumer#: An event or field is sent to the wrong consumer.

Communication.SendingAnEventOrFieldSendsSameSampleNtimes#: Instead of sending a sample (one data point) only once, it is send multiple times.

Communication.SendingEventDoesNotFreeResources#: Resources in the middleware that have been allocated with a previous allocation, are not freed after returning from send/update.

Destruction#

Communication.WrongResourcesFreed#: A destruction of one skeleton instances, frees the resources of another skeleton instance.

Communication.NoResourcesFreed#: The resources allocated on construction and during operation are not freed on destruction.

Communication.EarlyCleanUp#: Resources are freed while still being used.

Handle Method Calls#

Communication.WrongMethodInArgsUsed#: Unintended input arguments are used in a service method call. Therefore, the method call gets executed with wrong input data.

Communication.WrongMethodCalled#: Either the wrong user provided method handler is called or no user handler is called at all. Therefore, the method call results are invalid/garbage.

Communication.WrongResultsProvided#: The result of a method call is either not provided in the expected location, leaving uninitialized data in the expected location or it is provided in an inconsistent state. Therefore, the method call results are invalid/garbage.

Proxy#

Start Find Service#

Communication.StartFindServiceCallbackCalledUnexpectedly#: The user-provided callback is invoked, even though it should not be invoked.

Find Service#

Communication.ServiceNotFound#: A proxy does not find a service instance, even though it was offered by a skeleton.

Communication.WrongServiceFound#: A proxy instance finds a wrong service. This could be either a wrong service instance or a completely wrong service.

Construction#

Communication.ServiceIsFoundButDoesNotExist#: Finding a service, returns a service, even though no service instance was offered.

Stop Find Service#

Communication.StartedFindServiceIsNotStopped#: A user called “StartFindService” with a given handler, and since “StopFindService” does not work, services can still be found.

Communication.WrongStartfindserviceIsStopped#: The handle provided to StopFindService, is identified as another one and thus stops the wrong service discovery query.

SetReceiveHandler for an Event#

Communication.ReceiveHandlerNotInvoked#: A proxy has set a receive handler and a skeleton is updating an event, but the receive handler is never invoked.

Communication.ReceiveHandlerInvokedWithWrongEvent#: A receive handler registered for an event, gets called because of an update of an different event.

Communication.ReceiveHandlerInvokedMultipleTimes#: A receive handler is invoked multiple times, even though only one event update happend.

Communication.ReceiveHandlerInvokedWithoutEventNotification#: A receive handler is invoked, even though no event update happend.

GetNewSamples for an Event#

Communication.CallbackNotInvokedDespiteSamplesAvailable#: GetNewSamples() gets called on an event with a callback F, but the callback gets called not at all, although at least one new sample is available.

Communication.CallbackInvokedWithWrongData#: A proxy receives a sample pointer via callback F(), but the data does not contain the expected one.

Communication.UsesToManySampleptr#: User is already max. sample count SamplePtr, but we are still handing out SamplePtrs in callback F().

Communication.ReturnsWrongSampleCount#: Value returned by GetNewSample() does not match with the number of calls to callback F().

Communication.SucceedsDespiteAnError#: A user calls GetNewSamples() on a proxy instance and receives a sample count, even though he should have received an error.

GetFreeSampleCount for an Event#

Communication.ReturnsWrongFreeSampleCount#: A user has already M SamplePtr in use from a max. announced number N, but GetFreeSampleCount() returns a different value than N-M.

Unsubscribe for an Event#

Communication.DoesNotUnsubscribe#: A proxy is subscribed to an event, tries to unsubscribe, but silently fails to unsubscribe.

Communication.UnsubscribesFromWrongEvent#: A user unsubscribes from an event, but the unsubscribe is silently carried out on another event.

Communication.DoesNotImplicitRemoveReceiveHandler#: A proxy has registered a receive handler and unsubscribes, this should lead to the case that a receive handler is no longer called. In this failure mode, the receive handler would still be called.

Generic Proxy#

Generic access to Generic Proxy Events#

Communication.MapContainingNonexistentEvents#: The map that is visible to the user, contains events that are not actually existing (e.g. in the configuration).

Communication.IncompleteMapOfEvents#: The user gets presented not all events the generic proxy supports.

Generic Proxy Event#

Communication.TheSizeReturnedIsBiggerThenTheActualValue#: The user receives a size, that is bigger then the actual value.

Communication.TheSizeReturnedIsSmallerThenTheActualSize#: The user receives a size, that is smaller then the actual value.

Communication.WrongIndicationIfFormatIsSerialized#: A user, using HasSerializedFormat(), receives the wrong value.

Call Method#

Communication.MethodCallBlocksLongerThanExpected#: A call to a service-method on the client/consumer side blocks longer than expected (or indefinite). This is a specific instance of FailureMode [AnyFunctionBlocksLongerThanExpected], but since with service-methods we have concrete root causes in the form of message-passing behaviour and behaviour of user-provided handler, we have this specific failure mode.

Communication.WrongMethodInArgsProvided#: Unintended input arguments are provided to a service method call. Therefore, the method call gets executed with wrong input data.

Communication.WrongReturnValueUsed#: Unintended results are provided from a service method call. Therefore, the caller of the method works on wrong data.

SmartPointer#

SamplePtr and SampleAllocateePtr#

Communication.DoesNotFreeResourcesOnDestruction#: A SampleAllocateePtr or SamplePtr is destroyed, which should lead to a freeing of resources, but caused by a fault they are not freed.

Communication.FreesWrongResources#: A SampleAllocateePtr or SamplePtr free the wrong resources associated with them.

Communication.DoesNotReserveResources#: A SamplePtr or SampleAllocateePtr do not increase their respective ref-counts and thus avoid data changes.

Communication.DoesNotUpdateFreeSampleCountCorrectly#: When a SamplePtr gets created or destroyed for a given event instance, the Free Sample Count of this instance doesn’t get updated accordingly

Communication.ReturnsWrongData#: On dereferenciation of a SamplePtr or SampleAllocateePtr wrong data is returned.

MethodSignatureElementPtr#

Communication.MethodSignatureElementPtrWrongTarget#: On de-referencing of a MethodSignatureElementPtr wrong data is returned.

Communication.MethodSignatureElementPtrFailsToFree#: On destruction of a MethodSignatureElementPtr wrong memory is freed or not freed at all.

Root Cause Analysis#

Control Measures#

Communication.MonotonicSemiDynamicMemoryAllocation#: It shall be ensured that enough memory is configured for shared memory instances, in order that LoLa can perform all necessary allocations (e.g. push-back on a Vector).

Communication.CorrectlyConfiguredMaximumNumberOfSubscriber#: It shall be ensured that correct maximum number of subscriber is configured for each event for each service instance.

Communication.CorrectlyConfiguredMaximumNumberOfMaximumElementsPerSubscriber#: It shall be ensured that correct maximum number of elements per subscriber is configured for each event for each service instance.

Communication.CorrectlyConfiguredAsilLevel#: It shall be ensured that the ASIL Level on process level and per service instance is correctly configured.

Communication.OnlyLoLaSupportedTypes#: It shall be ensured that only types that are supported by LoLa are transmitted.

Communication.NoApisFromImplementationNamespace#: It shall be ensured that no API calls from the implementation namespace (e.g impl) are directly invoked or types from within are directly used.

Communication.NoGuaranteesForNotifications#: It shall be ensured that a miss behavior of event notification will not harm a safety goal.

Communication.CheckingForPossibleMessageOverflow#: It shall be ensured that a message overflow, which results in message loss will not harm a safety goal. If this is not possible, a check for message overflow and necessary actions need to be performed.

Communication.DifferentUserForAsilAndQmProcesses#: It shall be ensured that processes with a different ASIL shall be executed within different user-ids.

Communication.ConfigOnASafeFilesystem#: It shall be ensured that any configuration item that is read at runtime by LoLa is stored on a safety certified filesystem (according to the highest supported safety level).

Communication.NoStaticContextSupport#: It shall be ensured that LoLa is not used within static context within C++.

Communication.NoGuaranteeInAvailabilityOfServices#: It shall be ensured that no safety goal is harmed, because a service instance is not found.

Communication.NoNotificationOnTerminationOfProducer#: It shall be ensured that termination (either gracefully or due to a malfunction) of a producer will not lead to a violation of a safety goal.

Communication.SystemRestartOnLoLaProcessCrash#: Expectation: Crash of a LoLa enabled process (producer or consumer) doesn’t violate a safety goal. It shall be ensured that upon an unexpected termination of a producer or consumer, the whole system is restarted. I.e. NO selective restart of single processes, but a restart of the entire system.

Communication.CheckForNullptrOnAllocate#: It shall be checked if Allocate() on an event will return a nullptr. If a nullptr is returned, the system shall transition to safe state.

Communication.OneProducerOnlyOneAllocateePtr#: It shall be ensured that at any time a producer instance per event only holds one AllocateePtr.

Communication.NoCopySendWhileHoldingAllocateePtr#: It shall be ensured that Send(const& value) is not invoked while an AllocateePtr is held.

Communication.NoneReentrantMethodsPerEventInstance#: It shall be ensured that any LoLa API that is bound to a specific event instance is not called in a reentrant manner.

Communication.SkeletonAliveWhileItsAllocateePtrBeingUsed#: It shall be ensured that a Skeleton instance is still alive while any AllocateePtr returned by it is used.

Communication.EventSubscriptionActiveWhileHoldingSamplePtr#: It shall be ensured that Unsubscribe() isn’t called on a proxy event instance as long as any SamplePtr provided by it, is still held. Also the corresponding proxy instance shall be kept alive as on destruction it would implicitly call Unsubscribe().

Communication.NoneTerminatingCallbacks#: It shall be ensured that any callback passed to LoLa for invocation is not throwing.

Communication.ValidCallbacksWhileProxyAlive#: It shall be ensured that all callbacks passed towards LoLa are valid as long as the associated proxy is alive.

Communication.UnorderedElementsOnFullQueue#: It shall be ensured that the reception of elements in an unordered way on a full queue is not violating any safety goal.

Communication.QualityOfDataIsDependentOnProducer#: It shall be ensured that the necessary quality of data is produced by the respective skeleton process.

Communication.ValidityOfPointerOnLoLaPointer#: It shall be ensured that no pointer, pointing to the memory of a SamplePtr or AllocateePtr is used once the SamplePtr or AllocateePtr are invalid.

Communication.LoLaMemoryOnlyAccessedThroughLoLa#: It shall be ensured that no other code accesses the mapped memory managed by LoLa.

Communication.NoSharedMemoryAllocationInNamespaceLola#: It shall be ensured that no other code creates shared memory segments beginning with “lola”.

Communication.OnlyQnx71Supported#: It shall be ensured that any application containing LoLa is only executed on QNX Safe Operating System 7.1.

Communication.LoLaSpecificQnxMessagingEndPointsOnlyAccessedThroughLoLa#: It shall be ensured that the LoLa specific QNX Message Passing end-points are only accessed through LoLa APIs.

Communication.AragenNotSafe#: Input artifacts shall be manually reviewed for correctness

Communication.UnsupportedDataTypes#: It shall be ensured that neither variants nor maps are sent via LoLa.

Communication.NoGuaranteeOnExecutionTime#: There is no guarantee on the execution time of any function call provided by LoLa.

Communication.UsageOfConfigurationOversubscription#: If event instance “oversubscription” is enabled, LoLa makes no warranty that proxies/consumers can’t suffer from data loss! It is the responsibility of the user to adapt scheduling/event-data access in a way that no data-loss happens.

Communication.SameCompilerSettingsForProviderAndConsumerSide#: All compiler settings having influence on the binary representation of data exchanged via {{mw::com}}/{{LoLa}} (event, field, service-method payloads) have to be identical for compilation of code containing {{mw::com}} proxies and skeletons, which communicate.

Communication.EventOrFieldReceptionViaGenericProxyNeedsSpecificCare#: When receiving event or field data via untyped {{GenericProxyEvent}} or {{GenericProxyField}}, care has to be taken when accessing the corresponding {{SamplePtr<void>}} delivered by calls to {{GetNewSamples()}}: When casting it to the expected type, it needs to be checked that no access behind the size returned by {{GetSampleSize()}} will happen.

Communication.CorrectlyConfiguredEventsFieldsPerServiceType#: It shall be ensured that all safety relevant events/fields in the service type are the same in all configurations.

Communication.LoLaIpcCommunicationLostOrDelayedIpcCommunication#: [ISSUE:4542883] peers shall detect lost or delayed [ISSUE:4542883] communication by additional design measures on their [ISSUE:4542883] usage.

Communication.EnsureTheIntegrityAndReliabilityOfCommunication#: The Safety-Related Application Software and Safety-Related Platform Software shall ensure the integrity and reliability of communication by managing the following potential failure modes in the delivery of information: • Loss or delay of periodic or aperiodic events. • Loss or delayed delivery of a method call. • Loss or delayed delivery of a method response. • Loss or delay of field updates.

Communication.NoGuaranteesForTimelyMethodCallExecution#: It shall be ensured that a blocking method call will not harm a safety goal.

Communication.MethodInArgPtrMatches#: It shall be ensured that the memory locations of the method call in-arguments provided at the caller side are exactly the same as the memory locations as used at the callee side.

mw_com_fmea#

Failure Modes#

LoLa#

Skeleton#

Creation#

OfferAService#

StopOfferAService#

AllocateAnEventOrField#

SendAnEventOrField#

Destruction#

Handle Method Calls#

Proxy#

Start Find Service#

Find Service#

Construction#

Stop Find Service#

Subscribe for an Event#

SetReceiveHandler for an Event#

GetNewSamples for an Event#

GetFreeSampleCount for an Event#

Unsubscribe for an Event#

Generic Proxy#

Generic access to Generic Proxy Events#

Generic Proxy Event#

Call Method#

SmartPointer#

SamplePtr and SampleAllocateePtr#

MethodSignatureElementPtr#

Root Cause Analysis#

Control Measures#