Your comments

Thanks for the request, it is very interesting to see that this is being requested from different users.
To have a solution for this, we would need to develop a different hardware, as the hardware we have for the analog power driver ouputs (COUT/PWM/SOUT) we have today cannot be used to create an output signal in the 0-10 V or the 4-20mA range.
Hi Kevin, thank you for this interesting question. 

For the IQAN-MC3, the instruction books shows maximum achivable Safety Integrity Level (SIL2), which translates to Perfomance Level PLd when analyzing the safety function using EN 13849-1. All internal components on the IQAN-MC3 are included in this analysis, including the COUT and DOUT outputs.
For the IQAN-MC3, we also state the PFHd, Probability of Dangerous Failure per Hour, 2*10^-8

The PFHd is the final result of the calculation of hardware integrity, when diagnostics and structure is included, you can compare this result with the values in EN 13849-1 Appendix K.

I don't really see why you would need MTTFd for the IQAN-MC3? This should not be necessary, as this is only an intermediate stage. Note that the EN 13849-1 MTTFd is used on single channesl before diagnostics and structure is considered, not the final result. It would be possible to calculate this value, but it is only relevant if the internal IQAN-MC3 electronics was to be analyzed again using the so called "Simplified procedure for estimating PL" in EN 13849-1.
Instead, I recommend the method where you calculate the PL and PFH (using EN 13849-1 Appendix K) for the sensors subsystem and the hydraulics subsystem. Then add the sum of PFH for sensors, IQAN-MC3 and hydraulics, and check that you still meet the requirements on average probability of failure per hour in EN 13849-1 table 3.
(see EN 13849-1, 6.3 Combination of SRP/CS to achieve overall PL)

Also, I don't really see what the use of calculating MTTFd for the IQAN-MD3 and IQAN-XA2 would be?
It is wise of you to use the IQAN-MC3 for the safety functions, and use MD3 and XA2 controllers for the non-safety related functions on the machine. As the MD3 and XA2 are not used for any of the safety functions on the machine, then they would not be seen as SRP/CS (safety related part of control system) in any of the safety functions. And then calculation should not be necessary.

When you have two MD3:s in your project files, there are a couple of different ways the MD3:s can be connected.
For the multi-master system to work, the MD3:s must be connected using the Diagnostics bus. This will allow you to show values on both display pages from both applications, and measure groups, adjust groups and logs can be accessed on both displays.
To have more than one MD3 in the system, they must have unique addresses, you will need to use an IdTag on one of them to set it to a non-zero address. E.g. address 3.

To exchange real-time data between the applications, an easy way is to connect the "Master" bus, this will allow you to use the APPOUT/APPIN channels to send values between the two applications. What you will need to think of if you want to use the APPOUT is that it consumes a lot of bandwith, the APPOUT protocol was originally designed to allow MC3:s to communicate in a safe way, therefore this protocol has got a lot of overhead. If you have more than a handful of channels to send, I don't recommend this method. 
Note that channels that you only need to show on display pages don't need to go on the Master bus, these are automatically transferred on the Diagnostics bus.
One way to reduce the bus load on the diagnostics bus would be to put the Master(APPOUT) bus on a different CAN bus than the Diagnostics bus. 

The most efficient method is to use J1939 messages that you define yourself for any channel data that needs to be shared between the applications. You then add one J1939 module to represent messages coming from each MD3. The Source address you set (e.g. SA 40 = J1939 cab display) on the MD3, will also be set on the J1939 module in the system layout.

You can of coure add other non-IQAN J1939 modules to this bus also, just as you would normally do, and both MD3:s will be able to access the data from these

As Arno also points out, IQAN expansion modules added to a bus shared by two MD3:s is a special case.
You can have expansions on a bus shared between master modules, but only one of the master modules will own and be able to access the expansion module.
Thank you Niklas, good to hear that the problem you had was solved. It seems as if it was due to insufficient current capacity on the power supply.
Maybe.A 12 V supply with a capacity of 1 A should be enough to power the MD4.
Is the MD4 the only device you power via the 12 V supply?

With the backlight reduced to 50% (done automatically by the SW), the MD4-7 draws about 600 mA @12V.
Current consumption increase to about 750 mA @14 V (full backligth available), and then drops off again as the supply voltage increase.

One idea could be to measure the supply voltage via the MD4 using the module diagnostics to see if it is stable. For this, it is best to use IQANrun or a MDGN on a display page, (the MD4 module info in the menu system does not update automatically)
How do you supply the MD4 (e.g. battery on the vehicle or a fixed power supply on the bench) when you see this?
What is your supply voltage?

The MD4 has a function that automatically reduce backlight at supply voltage <14V. It drops linearly down to 50% at 12 V.
There is some hysteresis on the backlight reduction function, to avoid flickering due to small variations in supply voltage.
What SW version are you using on the MD4? We made some improvements to the backligth in version 3.15
Also, do you have a channel to control the backlight?
And is the screen-saver function on?
We have seen a problem with the screen saver interfering with the channel control of the backlight, but I believe that problem should be solved in 3.15
I have been able to reproduce the problem with 3.15 on the bench. 
What has happened with IQANdesign version 3.15 is that an XC10 that uses the module enable property gets status Disabled on the DOUT:s. This status remains on individual DOUT:s, even when the XC10 is enabled. 

The disabled status on the individual DOUT:s gets cleared by re-activating the DOUT (changing the input on the DOUT from false to true)
This bug might have been introduced as a consequence of preparing the version 3.15 for DOUT diangostics on the XC10. (requires a new FW version of XC10 that is not yet released). We will have to investigate.

I believe that you have used a module enable on the XC10 to handle another already know problem, that with quick restarting of the system,the MD3 powers up before the XC10 is ready?

A workaround for the moment could be to block the inputs to the DOUT when the XC10 is not enabled. The deactivated DOUT:s will still show the disabled status until activated, but if you use this workaround, you should not see any issues with the functionality.