A Device-Oriented Defi nition of Functions of Artifacts and Its Perspectives 219
Vermaas and Houkes (2006) emphasize that functions are relative to use plans and
human beliefs as follows:
A technical function of an artefact can be roughly described as the role the artefact plays in a use
plan for the artefact that is justifi ed and communicated to prospective users.... [F]unctions are
features that are ascribed by agents to artefacts relative to use plans, human beliefs and actions, and
bodies of evidence.
Here a function is a role played by an artifact in a use plan. Our external context depends
on such a “use plan,” though the functions in the ICE theory are based on an agent’s beliefs
on capacity and contribution, which are implicit in our defi nition. For a function of a
component, the “bracketed” ICE defi nition of component’s functions clearly captures its
dependence on composition in a system confi guration (Vermaas 2006). We revisit these
defi nitions in section 12.2.4.
The component function is similar to the constituent function (Johansson 2006) as
well:
A suffi cient and necessary condition for something’s being a constituent function is the following:
F is a constituent function borne by B if and only if: (a) there is a functional whole A; (b) B is both
a spatial part and a subunit of A; (c) B F’s in relation to some other entities (X, Y, Z) that are relevant
for A.
The embedded system in our terminology is precisely a functional whole. We try to
describe an engineering model of the relation and the relevance mentioned in condition
(c) in section 12.2.7.
Garbacz (2005) points out that a function is a state of affairs, which represents a con-
nection between objects and processes. Our defi nition tries to defi ne the connection from
the device-oriented point of view.
Notes
- Note that a behavior description depends on modeling assumptions made by a modeler. Behavior is indepen-
dent of the intentions of designers and users. - You could consider just a cooler instead of a radiator.
- Our discussion is mainly concerned with this full existence of functions that is being played by real behavior.
The discussion here on the existence of the function required by a user, at fi rst glance, seems to be applicable
to a function required by a designer in the early phase in the engineering design process. However, there is room
for further investigation because, unlike the use context, the function in the design phase seems to be insuffi -
ciently specifi ed for the existence of a function’s instance. We are currently investigating those issues on the
existence of a function. - Note that this sound-making function is only an external function and not a component function of
the heart for biological organisms. Many philosophers reject this function as a function of a heart (e.g.,
Wright 1973; Dipert 2006). We would also reject it under their defi nitions. As discussed in sections 12.2.4
and 12.2.5, our justifi cation is to treat “a function as a role of behavior” from an engineering point of
view. Moreover, the typical discussion of the rejection is about component and/or essential functions
of the heart, which we do not discuss here. Cummins recognizes that this function “sounds wrong in