it is common to want to write to a part of a data item. Examples:
1) One of more bits in an integral value: bits 0, 3, 5 in an 32 bit integer
2) one or more elements in an array: elements 3, 100, 101 in a 1000 element array
3) one or more fields in a structure

This feature has been demanded by our customers, and explicit support was added with explicit services in our PLCs and in our communications stack. When this is not available the only other way to write a single value within a larger data item (e.g. bits within a word) is to first read the item, modify it, and write it back. This creates risk due to the time lag between when the value was read and when the modified value is written back - the part that was not supposed to be modified may be "stale" and no longer the correct value. The need for a builtin service increases as the size in bytes of the item(s) increases because it takes longer to read it and write it back, raising the risk of writing "stale" data to the server, plus the comms + app layers are not real-time so cannot guarantee a response within a deadline.

Support for this to be optional so that servers that cannot guarantee RMW semantics are not forced to support it.

This mode is already optionally supported for arrays: indexed writes. The desired goal is to extend this to other data items where it makes sense.

Strawman proposal:

Whether or not RMW is supported for a fundamental type to be defined; e.g.
Abstract types not supported, only concrete types
Supported for all sizes of signed and unsigned integers, but not for floats or doubles.
Supported for words in a String or characters in a word
Not directly supported for some fundamental types: DateTime, LocalizedText, QualifiedName, BuildInfo, etc.

Arrays and structures
Arrays already support this per-element. This can be extended to the element itself if it is a supported data type. e.g. array of uint32 could support RMW for the bits in an element.
Structures can support RMW for fields within a struct; e.g modify the value of Field2 without changing the other fields.
Fields within a struct can also support RMW if the field's data type is a fundamental which supports RMW, similar to an array.

Each supported type should be optional with its own conformance unit. e.g. all signed/unsigned integers is one unit, strings another, etc.

Support for optional types to be reported in a server capability object.

Possible priority:
1) bits in signed/unsigned integers
2) Fields in a struct (replace entire field value)
3) bits in elements in an array
4) bits in Field when it is a signed/unsigned integer
5) bits in elements in Field when it is an array of signed/unsigned integer
6) words in string
7) characters in string
etc.