not familyFather.oclIsUndefined() is true for non-null and non-invalid, false for null or invalid
familyFather <> null is true for non-null, false for null, invalid for invalid (almost the same; the same for practical purposes).
If familyFather = null gives an error then something wierd is going on. Possibly familyFather is provably non-null because of a 1 lowerBound but I see no such lowerBound. It seems like EMFtoCSP has some questions to answer.
I contacted with its developer and he said "one of the limitations of the EMFtoCSP tool is the lack of support for OCL's three valued logic. The null and undefined values are not supported by the tool, so you can get unexpected error messages if you use them in your OCL code".
You could upgrade EMFtoCSP to support at least null and possibly invalid.
You could modify your modeling to make NULL / INVALID as explicitly modeled concepts.
You could modify your modeling to prevent any usage of null / invalid.
- the safe navigation analyses enable most forms of unsafe null to be detected, non-zero lowerbounds prohibit null
- you might use a variant OCLstdlib to exclude null support
- you might exploit the org.eclipse.ocl.pivot.internal.manager.InvalidAnalysis on the Lazy Collections branch (ewillink/509670) to prove that your expressions are invalid-free
Beware; the independent InvalidAnalysis might be integrated extending [?] (may-be-null) or  (may-not-be-null) element multiplicities in the grammar with [/] (may-be-invalid-or-null) and introducing Nullable<T>, Invalidatable<T> wrapper types to model them in the AST.